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Preface 



This volume contains the papers selected for presentation at the 17lh IFIP WG 
1 1 .3 Working Conference on Database and Application Security. The Con- 
ference was held on 4-6 August 21XD3, in Estes Park. CO. USA. It describes 
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REMOTE COMPUTER FINGERPRINTING 
FOR CYBER CRIME INVESTIGATIONS 



Jon Novotny, Dominic Schulic, Gavin Manes and Sujcci Shenoi 
Center for Information Securitw University ofTutsa. Tuha. Oklahoma 74104, USA 

A bsiracl This paper describes i novel tool for remoiely “ fi n ge rpr i n( I ng ” computers used in 

criminal aciiviiy. The tool employs network scanning and machine idemificalion 
techniques lo acquire a fingerprinl of a computer over (he Inlcrnei. The fingerprint 
includes identifying information about the operating system, banners, enumer* 
ations and services. Once the computer is seized, it is connected to a clo.sed 
network and scanned again to produce a .second fingerprint to check against the 
original. Two .scenarios - one related to investigating pedophiles and the other 
involving an illegal website - are examined. Legal issues pertaining to the use 
of computer fingerprinting in criminal investigations are also discussed. 

Keywords: Computer Forensics, Digital Evidence, Computer Fingerprinting 

1. Introduction 

The goals of a criminal invesii gallon arc to acquire evidence of illegal ac- 
tiviiy and lo conclusively establish the role of ihc suspeci. In a cyber crime 
invcsligaiion, it is necessary to identify the devices (compuicrs. cell phones, 
PDAs, eic.) used in the illegal activity and lo establish lhat the suspect used 
ihosc devices in the crime [20). 

Networked computers are increasingly used in illegal acliviiies [6]. For 
example, Internet chai rooms arc often used by pedophiles to reach potential 
viciims: according lo one survey. 19% of young people between the ages often 
and seventeen who used the Internet at least once a month received unwanted 
sexual solicilaiions (13). 

Law enforcement agents sometimes pose as minors in chal rooms to catch pe- 
dophiles [2, 11). In atypical scenario, an undercover detective and suspect meet 
in a chal room, communicate using chat room applications and/or direct mes- 
saging (e,g., e-mail), and arrange a sexual liaison at which lime ihc pedophile 
is arrested (17). The evidence includes recorded chat room conversations and 
direct messages, which demonstrale an intent lo engage in sex with the '‘minor” 
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Figure 1. Remote machine fingerprinting. 

and the details of the rendezvous |12]. The suspeet is lied to this evidence when 
he/shc is ancstcd at the rendezvous point. 

Remote fingerprinting can be used to obtain evidence that the suspect's com- 
puter was the one used to communicate with the undereover detective. This 
“machine fingerprint" includes identifying information about the operating sys- 
tem, banners, enumerations and services of the suspect's computer. After the 
suspect is arrested and his/her computer is seized, it is scanned again to produce 
a new fingerprint. Matching the new fingerprint with the remotely aequired one 
ean help establish that the seized eomputer was used in the crime. 

The remote fingerprinting strategy is presented in Figure I. The fingerprint- 
ing tool employs network scanning techniques 1 1 ,7.8] to acquire a fingerprint of 
a target machine over the Internet, The fingerprint is cryptographically sealed 
along with other electronic evidence (e.g., chat room and and e-mail transcripts). 
While it is preferable that the target machine be configured to permit network 
scans, it is possible to obtain useful identifying information even when it em- 
ploys network defense mechanisms. 



2. Network Scanning Tools 

The hacker community was the first to use network -based machine explo- 
ration. Their goal was to identify hosts with speeific vulnerabilities that eould 
be exploited. Interestingly, generalized versions of early hacker tools are at 
the core of current strategies for mapping networks, identifying machines and 
discovering vulnerabilities - all intended to secure computing a.sscts. Popular 
tools like Nmap [5] and ENUM arc in fact the direct result of ideas, scripts and 
programs originally developed by haekers. 

Nmap is an open source utility for network exploration and security auditing 
15,8], It transmits IPpaekets in carefully designed sequences to identify network 
hosts, open ports, services, operating systems and versions, packet filters, and 
firewalls, among other information. Nmap, however, has two shortcomings. 
First, Nmap was not developed to uniquely identify single machines; rather, it 
offers a broad view of multiple machines to locate common attributes. Second, 
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N map is not appropriate for cyber investigations because it docs not ensure the 
accuracy and integrity of the data ii acquires. Indeed, this limitation is true for 
all the tools discussed in this section, 

ENUM, along with the more recent ShareScan and Nctcal tools, can enumer* 
ate NetBIOS and Samba information, including network shares, user accounts 
and password policies. The Unix finger command similarly provides infor- 
mation about network/host users, including full name, default shell and login 
times. 

Two other popular tools arc Nessus [16] and LANGuard [10]. Ncssus uses a 
set of plug-ins to test for the presence of various services and their vulnerabil- 
ities. It can distinguish between an SMTP server running on port 25 and port 
3005; however, it uses a brute force approach that requires frequent updates. 
The LANGuard scanner can identify operating systems and obtain operating 
system specific information. It also enumerates NetBIOS groups on hosts run- 
ning Microsoft operating systems and SNMP properties on network printers. 

Although current network scanning tools gather useful information about 
target machines, no single tool provides all the desired capabilities and ensures 
information integrity, which is required for remote fingerprinting. What is 
needed is a comprehensive, reliable tool for remote machine fingerprinting that 
will meet the rigorous standards of evidence. 

3. Remote Fingerprinting System 

The remote fingerprinting system refines existing network scanning tech- 
niques to acquire a fingerprint of a target machine over the Internet, All 
machine- specific information constituting a fingerprint is available without au- 
thentication or is available anonymously, and can be acquired by any machine 
connected to the Internet. No intrusion into personal data, including files and 
their contents, is attempted. When a machine connects to the Internet, it uses 
various protocols (TCP, UDP, etc.) and ports (1-65535) and applications run- 
ning on these ports (ftp 21, telnet 23, etc.). This information and data 
gathered from the network stack and active services arc used to produce a fin- 
gerprint. All the information gleaned is time-stamped, cryptographically sealed 
and stored in an evidence container (e.g.. hard disk). 

Network enumeration is the most intrusive technique used by the finger- 
printer, as it potentially provides a list of files and computer settings. Note, 
however, that an enumeration only yields the list of resources that the user has 
chosen to share with other computers. Storing a hash value of the resource 
list instead of the list itself can mitigate the intrusiveness of this technique; 
fingerprint comparison would then check the stored hash value. 

Remote machine fingerprinting has three components: open port identifi- 
cation. operating system detection and service analysis (Figure 2), Service 
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Figure 2. Machine Hngerprinl components. 

analysis has four subcomponcms: service verificaiion, service bannering, ser- 
vice exploration and service exploitation. One or more of these components can 
constitute a machine fingerprint. Obviously, incorporating more components 
produces a better (more detailed) fingerprint, 

3.1. Open Port Identitlcation 

Open ports arc identified using a specially designed Java-based host port 
mapping tool. The list of open ports provides a foundation for operating system 
detection and service analysis. 

The port mapping tool uses the full connect and SYN stealth techniques to 
identify open ports [8]. The full connect technique attempts to open a Java 
socket with the remote port, which requires a full TCP handshake. The SYN 
stealth technique transmits the initial SYN packet in the TCP handshake and 
w ait s f or a S YN- AC K packet . S YN scann in g require s f e wer packets ( i t is fas ter) 
and can go undetected (half-open connections arc less likely to be logged than 
full TCP connections). The port mapper efficiently scans all 65,535 ports, alert 
to the fact that users "hide" certain services in uncommon port ranges to avoid 
detection. 

3.2. Operating System Detection 

The TCP stack of a target machine is probed by transmitting a set of seven 
TCP packets. The responses arc analyzed to infer operating system (OS) infor- 
mation, 

TCP packets transmitted to the target machine vary slightly in their control 
bits and whether they are sent to open or closed ports [9,15). The responses 
to these packets arc dependent upon the TCP stack of the target machine, and 
help identify the OS, often down to version and/or kernel build. 

TCP/IP stack analysis relies on two closely related facts. First, network pro- 
tocol specifications are evolutionary in nature. For example, explicit congestion 
notification (ECN) proposed in RFC 3168, gives routers the ability to notify 











Remote Computer Fingerprinting for Cyber Crime Investigations 



1 



Fingerprint 




Figure 3. Operatiug system ideutincation. 

sending and receiving parties of persistent network congestion using certain IP 
and TCP header fields [18], ECN is now filtering its way into network OSs, 
and is being used by some (not all) implementations. Checking the ECN field 
distinguishes OSs that use it from those that do not. Second, vendors often view 
protocol standards as recommendations, resulting in implementation variations. 
One example is the use of reserved space within packets, where some vendors 
evidently interpret reserved to mean "saved for vendor use.” Such variations 
help differentiate between OS specific network protocol implcmenlalions. 

Figure 3 displays the databa.se schema used in OS detection. The main table 
(Fingerprint) links each of the individual tests into a single fingerprint, which 
identifies the OS based on the test results. The other nine tables arc used to 
store the defining attributes of a response packet, like Window Size and TCP 
control bits. These tables arc linked using the test identifier (TID) attribute, 
where each TID represents a unique response received from the probe packets. 
This organization improves efficiency because many responses arc identical 
according to our criteria. 

3.3. Service Analysis 

Service-related information is acquired by service analysis, which includes 
service verification, service bannering, service exploration and service exploita- 
tion, and uses the list of open ports provided by the port mapping tool as its 
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starting point. Analyzing the network services offered by the target machine 
provides information which differentiates the machine and is an important com* 
ponent of its fingerprint. 

Service verification confirms the identity of services, regardless of their port 
numbers. This guards against ca.ses where users mask possibly malicious in- 
lentions by hiding common services on uncommon ports. Verification is im- 
plemented using finite stale machines. By focusing on RFC and vendor (e.g„ 
ssh.com) specifications, service verification is only a matter of identifying and 
encoding core commands and responses. Figure 4 presents the finite slate ma- 
chine used for POP3 service verification. 

Service banners provide a wealth of information about a machine and its users 
[9|. Default banners for telnet and ftp may identify the operating system 
down to its kernel build. Personalized banners, e.g., call signs and computer 
names, provide valuable identifying information. The service bannering utility 
connects to the available services and captures all the information offered before 
authentication. e,g., identifiers, greetings and prompts. 

The service enumeration utility lists anonymously available data provided 
by a service or services. The data may include files represented in tree form 
from an http server or an ftp service, usernames, drives and direelories on 
a machine. SMTP server settings, operating system password policies, routing 
tables, printer trays and paper types. 
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Figure 4. POP3 .service verlilcadou. 

Service exploitation has limited (if any) investigative applications as it po- 
tentially involves illegal activity. This technique works by identifying and 
exploiting vulnerabilities to obtain private information. 



3.4. Fingerprinting Results 

Identifying specific machines in networks driven by standardization and in- 
teroperability is difficult. However, malicious individuals often mask their 
identities and activities, e.g., by hiding chat room or file sharing services on un- 
common ports, by modifying service banners, or by employing network security 
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Figure 5. Fingerprint resuJt*; for a pro<luetion network. 



mechanisms. The remote flngerprintcr thrives on the uniqueness introduced by 
such actions. 

Figure 5 summarizes the results of remote fingerprinting performed on a 
production network of 340 computers. Only two components - commonly 
used (2,048) open ports and operadng system - arc considered. More than 50% 
of the machines have identical profiles ba.scd on the two fingerprint components. 
Even so, eight machines are uniquely identified, and many more arc grouped 
with three or fewer other machines with the same fingerprint. This is significant 
because computers used in illegal activities would likely fall in one of the 
smaller fingerprint groups or be uniquely identified. Indeed, when additional 
identifying components arc used, the uniqueness of fingerprints is even greater, 

4. Investigative Scenarios 

The fingerprinting technique can be used to good effect in a variety of inves- 
tigations. Two common scenarios, one related to investigating pedophiles and 
the other involving an illegal website, arc discussed. 

Children arc increasingly exposed to pedophiles on the Internet [6.11]. In 
the past, pedophiles would prey on children at school playgrounds, parks and 
neighborhoods; now they target children from the privacy of their own homes. 
According to one survey [13], 19% of young people between the ages of ten 
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and sevcnlccn who used the Internet at least once a month received unwanted 
sexual solicitations. 

Pedophiles frequently use Internet chat rooms to reach potential victims 
|6,17|. The chat room conversations and e-mail exchanges may escalate to 
meetings intended to consummate the online relationships. Sometimes these 
meetings progress beyond sexual abuse and rape, including kidnapping and 
murder [13]. 

One strategy used by law enforcement to apprehend online pedophiles is 
illustrated in Figure 6. An undercoverdctectiveposing as a minor communicates 
with a suspect in an Internet chat room. The detective builds a relationship with 
the suspect through repealed chat room communications and via direct messages 
(e.g.. e-mail or instant messages). During the communications, the detective 
arranges a liaison with the suspect. Often, the detective asks the suspect to bring 
something (e.g., stuffed animals, alcoholic beverages or sexual paraphernalia). 
The item requested in Figure 6 is Duff Beer. When the suspect is apprehended 
at the rendezvous point with the requested items, there is evidence that the 
suspect was the individual who communicated with the undercover detective in 
the chat room. 

The evidentiary strategy can be viewed as completing the triangle in Figure 
6. First, all chat room conversations and direct messages, including the request 
to bring Duff Beer, must be captured and scaled as evidence. This evidence 
is acquired using chat room logging tools, monitoring software or by simply 
videotaping over the detective's shoulder [12,17]. Then, it is necessary to tie the 
suspect's computer (after it has been seized) to the scaled chat room transcripts 
(side I in Figure 6). Next, the suspect must be linked to the seized computer 
(side 2), 

The remote fmgerprinter and a simple chat room monitoring tool help com- 
plete sides i and 2 of the evidence triangle. The chat room monitor logs con- 
versations and direct messages, and the remote fingerprinter links the suspect's 
machine to the recorded transcripts. Matching the remotely acquired finger- 
print with that of the seized computer establishes that the suspect’s computer 
was used for the online communications. Side 3 of the triangle is established 
when the suspect is arrested at the meeting place with the items (e,g.. Duff Beer) 
that were specifically requested by the deteedve in the logged communications. 

Another potential application of remote fingerprintering involves acquiring 
information about a website host, e g., one offering child pornography or one 
belonging to a suspected terrorist group. In such a case, the fingerprinter can 
be used to identify the web server for when it is eventually seized. 

Remote fingerprinting has many other applications. In all ca.ses, it is impor- 
tant that the fingerprint be sealed (e,g„ using MD5 hashing) like other electronic 
evidence [20]. Moreover, chain- of- custody and evidence storage standards 
must be guaranteed [20,22.23]. 
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Figure 6. Pednphile invesrigalion. 



5. Legal Issues 

No evidence acquisilion technique or tool should be employed without exam- 
ining the legal implications. This section considers the admissibility of remote 
fingerprinting evidence and the legality of its use by law enforcement. 

5.1. Admissibility of Evidence 

Admissibility refers to the principles determining whether or not particular 
items of evidence may be admitted into a court of law [22]. In the United States. 
Supreme Court decisions and the Federal Rules of Evidence (F,R,E.) define the 
criteria for the admissibility of novel scientific evidence [20,22). 

In the landmark 1993 judgment. Daubert v, Merrell Dow Pharmaceuticals, 
the Supreme Court cast upon trial judges the duty to act as gatekeepers charged 
with preventing] unk science from entering the courtroom [14]. To assist judges 
in this role, the decision specified four factors: testing, peer review, error rates 
and acceptability in the relevant scientific community. The Daubert case em- 
phasized that a judge’s inquiry is a flexible one, and its focus must be solely 
on principles and methodology, not on the conclusions that they generate. Al- 
though other cases have recognized that not all four Daubert factors apply to 
every type of expert testimony (see, e.g., Kumho Tire Co, v. Carmichael; Tyus 
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V. Urban Search Management), the factors can be helpful in estimating the 
admissibility of evidence produced by remote fingerprinting (14|. 

It is also necessary to consider issues related to F.R.E, requirements. In 
Rule 702, the requirements state: “If seicntific, technical or other specialized 
knowledge will assist the trier of fact to understand the evidence or to determine 
a fact in issue, a witness qualified as an expert by knowledge, skill, experience, 
training, or education, may testify thereto in the form of an opinion or otherwise, 
if (1) the testimony is based upon sufficient facts or data, (2) the testimony is 
the product of reliable principles and methods, and (3) the witness has applied 
the principles and methods reliably to the facts of the case” (14], 

Thus, the reliability of scientific evidence is supreme in determining its ad* 
missibility. This rule guides the use ofDNA evidence in federal courts [14], 
For example, since 19S7 • when DNA evidence was first used in a criminal 
case • the evidence has generally been admitted in federal courts when it can 
be verified that DNA testing has been reliably applied. In the majority of cases 
in which DNA evidence has not been admitted, the reasons were that scientific 
techniques were not applied properly andyor ehain*of*euslody standards were 
not met. 

Remote fingerprinting is obviously not as mature as human fingerprinting 
or DNA testing. As with these techniques, the technology should advance 
with time to become sufficiently reliable. But unlike human fingerprinting and 
DNA testing, remote fingerprinting may not provide a “unique” identification. 
Rather, wc believe that a remote fingerprint - properly acquired and preserved 
“ would constitute one more indication that the seized machine was used in the 
illegal activity, 

5.2. Federal Law 

If law enforcement fails to respect the privacy of individuals in its investiga- 
tions, evidence will be suppressed and criminals will escape prosecution [3,20], 
More importantly, the citizenry's confidence in government will be eroded. 

U.S, federal law governing law enforcement's acquisition of electronic evi- 
dence in criminal investigations has two primary sources: the Fourth Amend- 
ment to the U.S, Constitution, and the statutory privacy laws in the Wiretap 
Statute (IS U.S.C, Sections 2510-22). the Pen/Trap Statute (IS U.S.C, Sections 
3121-27) and the Electronic Communications Privacy Act (ECPA) of 1986 (IS 
U.S.C. Sections 2701-2712) [19,22]. The ECPA regulates how the government 
can obtain stored account information from network service providers; remote 
fingerprinting docs not involve such information, therefore the ECPA is not 
relevant to this discussion. 

5.2.1 The Fourth Amendment. The Fourth Amendment limits the ability 
of government agents to search and seize evidence without a warrant. We 
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consider the conslitutional limiis on warranllcss searches in cases involving 
computers. According to the Supreme Court, a warrantless search does not 
violate the Fourth Amendment if: (i) the government’s conduct docs not violate 
a person's “reasonable expectation of privacy,” or(ii) the search falls within an 
established exception to the warrant requirement (4,22.23]. 

The most relevant exception to the warrant requirement pertaining to remote 
fingerprinting is plain view. To rely on this exception, “the agent must be 
in a lawful position to observe and access the evidence, and its incriminating 
character must be immediately apparent” (22], The exception merely permits 
an agent to seize evidence that hc/she is authorized to view under the Fourth 
Amendment. 

The Fourth Amendment also restricts the government's use of innovative 
technology to obtain information about a target [4,22], In Katz v. United Stales, 
the Supreme Court ruled that a search is constitutional if it docs not violate a 
person’s “reasonable” or “legitimate” expectation of privacy [22]. Therefore, in 
the case of remote fingerprinting, it is ijnportant to assess whether or not an in- 
dividual with a computer connected to the Internet has a reasonable expectation 
of privacy regarding his/her services and bannering inforjnation. 

Kyllo V. United Slates is also relevant [22], In this case, the Supreme Court 
held that the warrantless use of a ihertnal imager to reveal the relative amounts 
of heal released from the various rooms of a suspect’s home was a search that 
violated the Fourth Amendment. In particular, the Court held that where law 
enforcement “uses a device that is not in general public use, to explore details 
of the home that would previously have been unknowable without a physi- 
cal intrusion, the surveillance is a 'search' and is presumptively unreasonable 
without a warrant,” Use by the government of innovative technology, such as 
remote fingerprinting, which is not in general use to obtain information frojn 
a suspect's computer may implicate the Kyllo ruling. This suggests that law 
enforcement may not employ remote fingerprinting without a warrant. 

The Supreme Court, however, restricted its holding in the Kyllo case to the 
use of technology to reveal information about “the interior of the home” [22]. 
Therefore, it can be argued that the Kyllo case would not apply to the use of the 
remote fmgerprinter because the information gathered would metaphorically 
lie outside the home, within the public domain of the Internet. 

5.2.2 The Wiretap and Pen/Trap Statutes. The Wiretap Statute (18 
U.S.C, Sections 2510-2522), generally known as “Title HI,” is the most im- 
portant federal statute governing real-time electronic surveillance in federal 
criminal investigations [21,22]. Title III broadly prohibits the “interception” of 
oral communications, wire communications and electronic communications. 
Failure to comply with this statute may result in civil and criminal liability, 
and in the suppression of evidence. However, Title III contains an exception 
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permitting law enforcement officers to intercept communications in which they 
arc a party to the communication. This “under color of Iaw“ exception makes 
Title III a relative non*issue for remote fingerprinting |22]. 

The Pen/Trap Statute (18 U.S.C. Sections 3121-3127) governs the use of 
pen registers and trap and trace devices to collect address information and 
other non-content information for wire and electronic communications [22|. 
Because law enforcement officers arc legally permitted to access the entire 
communication by the “under color of law*' exception to Title III when they 
are party to the communication, it is reasonable to assume that they would be 
permitted to intercept the address information as well. Therefore, the Pen/Trap 
Statute would not pose a barrier to law enforcement officers using the remote 
fingerprinler. 

5.3. State Law 

In addition to the applicable federal statutes, state law must also be con- 
sidered, Although the “under color of law” exception to Title III may permit 
law enforcement officers to intercept communications in which they are one 
of the parties to the communication, not all state wiretap laws have this same 
exception. Indeed, some state wiretap laws require the consent of all parties to 
a communication. Because state law varies considerably in this regard, we rec- 
ommend that law enforcement officers be familiar with the particular state laws 
in effect where an investigation lakes place, aware that remote fingerprinting 
may require a warrant, 

6. Conclusions 

As the scope and magnitude of cyber crime increase and the specter of cy- 
ber terrorism rears its head, it is imperative to design sophisticated forensic 
tools for acquiring evidence that will help identify, apprehend and prosecute 
suspects. Remote fingerprinting is a novel technique for identifying computers 
on the Internet. The machine fingerprint, which includes detailed information 
about the operating system, banners, enumerations and services, may not pro- 
vide a “definitive" identifier like a human fingerprint or DNA sample. Still, 
a remote machine fingerprint, legally acquired and properly preserved, is one 
more objective indication that a seized computer was used in a crime. 
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Ab&Lract; A database log is the primary resource for damage assessment and recovery 
after an electronic attack. The log is a sequential file stored in the secondary 
storage and if can grow to humongous proportions in course of time. Disk I/O 
speed dictates how fast damage assessment and recovery can he done. To 
make the process of damage assessment and recovery more e^dent, 
segmenting die log based on different criteria has been proposed before. But 
the trade off is that, either segmenting the log involves a lot of computation or 
damage assessment is a complicated process. In this research we propose to 
strike a balance. We propose a hvbrid log segmentation method that nil/ 
reduce the time taken to perjbrm damage assessment while still segmenting the 
log fast enough so that no intricate computation is necessary. While 
performing damage asse.tsment. we re-segmenf the log based on tran.taction 
dependency. Thus during repeated damage a.s.'iessmenf procedures, we create 
new .\egmenfs with dependent fran.\actions in them so that the process of 
damage as.tessmenf becomes faster when there are repeated attacks on the 
.tystem. 

Ke y words : Database log. damage assessmeni, log segmentaiion , iransaciion dependenc y 



1. Introduction 

Ever since ihc dawn of Ihc Internet, there have been reports of 
unauthorized entry into computer systems and rendering them inconsistent 
and unstable. There are many methods to protect a system from such attacks 
but savvy hackers always find newer ways to break into a system and use it 
maliciously. Several intrusion detection mechanisms have also been 
developed. But those methods do not detect an intrusion as soon as it 
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occurs. This results in the damage caused by the malicious user to spread 
throughout the system in an exponential manner. In course of time, the 
system may become so unstable that we have to shut the entire system down 
in order to bring it back to a consistent state. This is highly unacceptable in 
time critical database systems where valid users must have access to data at 
every, and all times. Hence the next best solution to the problem would be 
to design fast and efficient damage assessment and recovery algorithms to be 
used during the post intrusion detection scenario. 

Traditional logging mechanisms as described in [2], |5|, and [3]. record 
only the “write” operations of a transaction, A traditional log docs not 
suffice to recover a database from an attack, as it does not contain the “read” 
operations of the transaction. Read operations arc essential to establish 
dependences among transacdons and data items. 

To expedite the process of damage assessment and recovery after an 
attack, the log can be segmented based on certain criteria. That way, when 
an attack is detected, wc can skip large portions of the log. which, we arc 
sure, docs not contain malicious or affected transactions. 

Several log segmentation approaches have been devised. Notable among 
them arc the transaction dependency based approach [8], the data 
dependency ba.sed approach llOJ, and segmenting based on certain criteria 
like fixed number of transactions, time window for transactions to commit 
and space for committed transactions [11], In this research, wc propose to 
devise a hybrid method of log segmentation that uses the approaches 
presented in [8] and [1 1] so that damage assessment and hence recovery can 
be expedited. 

The rest of the paper is organized as follows. In section 2, the prior work 
and the motivation behind this research are described. In section 3, 
descripdon of log re-segmentation with accompanying cases and algorithms 
arc presented. In section 4, the damage assessment model using the re- 
segmented log is described. Section 5 presents the simulation results. 
Section 6 concludes the paper. 



2. Prior Work and Motivation 

In [4], the researchers have proposed several guidelines for trusted 
recovery. Amman et al. [1] followed a transaction dependency approach 
that uses relationships among transactions to identify and repair dajnagc in 
the database. Panda and Giordano [9| adopted a data dependency approach 
to recover from malicious attacks. Reordering transactions for efficient 
recovery has been discussed by Liu et al. [6]. A distributed recovery 
approach has been offered by Liu and Hao in [7]. But all of these 
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approaches scan a sequential log file, which is very huge. Log segmental ion 
techniques using transaction dependency and data dependency were 
presented in (8] and [10] respeclively. These methods segment the log file 
in such a way that all dependent transactions (or depcndenl dala*itcms in the 
ease of data dependency segmentation) arc stored in one segment. By doing 
so. it can be made sure that we do not have lo scan a large portion of the log 
when an attack is detected. 

But a major drawback in these approaches is that they use valuable 
system resources to perform intricate computation to delerminc dependences 
among transactions or data-iteins while the execution of the transactions is 
still on. Also, there is a chance of a segment growing too large because too 
many transactions or data*itcms may be dependent on one another. Different 
segments have a chance of merging into one segment and ullimalely it could 
be one huge scgmcnl. as big as the log itself. This defeats the purpose of log 
segmental ion. In (11| researchers have presented methods of segmenting the 
log based on number of transactions, a time window for transactions to 
commit and fixed space for committed transactions. In the first method, a 
segment is formed after a fixed number of transactions commit. In the 
second approach, there is a time window provided for transactions to 
commit. All transactions that committed in that time frame form one 
segment. In the third method, the space for a segment remains fixed. All 
committed transactions that fit into that segment are stored. Transactions arc 
not allowed to span from one segment to another. Thus the size of each 
segment is kept under control and running the risk of a segment growing too 
big is avoided in all these three approaches. Also, each of these methods 
uses very little computation while segmenting the log. However, a 
significant amount of compulation has to be done to determine the 
dependences among the segments during damage assessment. In scenarios 
where attacks arc quite frequent, this method may not yield the fastest 
solution to recover a database. 

In this research, we present a hybrid method of log segmentation that 
uses the techniques provided in [11] and [8]. We propose lo further segment 
a log already segmented based on any of the three approaches described in 
[11] based on transaction dependency approach as described in [8j. We 
shall do the re- segmentation while assessing damage during subsequent 
attacks on the database. By doing so. we intend to achieve a significant 
improvement in terms of time required during datnage assessment while still 
keeping the log segmentation algorithm simple enough so that the lime for 
execution of transactions is not hindered. 
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3. Hybrid Log Segmentation 

Our model is based on Ihc following assumptions: (a) Transaction 
operations arc scheduled in accordance with the rigorous two-phase locking 
protocol as defined in [3j, (b) Read operations arc also recorded in the log 
file, (c) Intrusion is delected using one of the intrusion detection techniques 
and the id of the attacking transaction is available, (d) The log is never 
purged, and (e) Blind writes are not allowed. Below, a list of definitions is 
presented that are helpful in understanding the research and the algorithms. 

Definition J: Transaction Tj is said to be dcpendcnl on transaction T, if Tj 
read one or more data items that was previously written by the comm it led 
transaction T,. 

Definition 2: A tuft is a group of transactions that adheres lo any one of 
the three models presented in 111], The transactions in a lufi arc stored in 
the chronological order in which they committed. It is represented as Tj 
where 'i’ denotes the lufi number. 

Definition 3: A read_iiems list is a list of all the data items that were read 
by all the transactions in a segment. 

Definition 4: A 'ftrite_iiems list is a list of all the data items that were 
written by all the transactions in a segment. 

Definition 5: A iuft_iable is a table that contains the transaction number 
and the luft in which it is present. 

Definition 6: Anaffected_iiemsVi%\ contains all the data items that were 
written either by a malicious or an affected transaction. 

Definition 7: A transaction is said to be affected if it updates the value of 
a data item using the value of another data item that was previously written 
by either a malicious or another affected transaction. 

Definition 8.' A '‘size -control led -segment" is a segment that was created 
using one of the three approaches described in [11], In other words, we 
choose to call a tuft as a sizc-controlled-scgment. 

Definition 9: A “size -un-control led -segment" is a segment that was 
created using transaction dependency. 

The log segmented based on any of the three approaches described in 
[11] can be pictorially represcnled as shown in Figure 1. 




Figure /: Log Segmenli before Rc'Segmeniation 



Re -segmenting the log begins after an attack is detected and the attacking 
transaction is available. The process is done during the damage assessment 
phase. Let us assume that an attack was detected in fj. It has been shown 
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lhai scanning of transactions in Tj is unnecessary because none of the 
transactions in read a data item written by any of the transactions present 
in Tj. Rigorous two-phasc locking protocol ensures this. The attacking 
transaction in is determined using the iufi_iable. Ail transactions in all 
the segments until the last affected segment, i.e, the segment that has the last 
affected transaction in it, arc scanned. A new segment is started with the 
first malicious transaction in it. To determine the dependency among 
transactions, we intersect the “write" set of the malicious transaction with 
the read set of the transaction to be scanned. There are two cases, as 
discussed below, depending upon the results of the intersection. 

3.1 The result is not a null set 

The transaction is affected. That particular transaction is stored in the 
newly formed segment that contains the malicious transaction and other 
affected transactions. The data items that were written by the transaction arc 
appended to the affected _iiems list. Thus all malicious and affected 
transactions will be present in one segment at the end of the damage 
assessment phase and all affected data items in the affeciedjiems list. 

3.2 The result is a null set 

This means that the transaction did not read any affected data. The 
“read” and the “write” sets of the transaction arc stored in a new readjiems 
list and wriiejiems list respectively. We can be sure that the transaction is 
not dependent on any other transaction in any of the other si zc-un -control led 
segments that were formed. Hence a new segment is created and the 
operations of the transaction arc stored in it. 

During subsequent scanning of transactions, the “read" items of that 
transaction is intersected with all the wriiejiems lists and affeciedjiems list 
available to determine if there is a dependency between the transaction and 
the segments. By doing so, it is checked whether the transaction read a data 
item that was previously written by another transaction. If the result of all 
the intersections is a null set, it means that transaction is completely 
independent of all other transactions scanned so far, A new segment is 
created and the operations of that transaction arc stored in it. Also, a new 
readjiems list and a wriiejiems list is started as in the previous case and 
the “read” set and the “write” set of the transaction arc stored into the 
respective lists. 

If on the other hand, the result of the intersection of the “read" set of the 
transaction with two or more wriiejiems lists is not a null set, it means that 
the transaction is dependent upon two or more transactions that arc present 
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in two different segments. In such a case, those two segments arc merged 
and the operations of the current transaction are stored in the merged 
segment. The readjxems list and the write Jiems list arc also merged and 
the “read” set and the “write” set of the transaction are stored into the 
appropriate lists. 

If the transaction is dependent on only one of the segments that have 
been formed, it is added to the end of the segment upon which it is 
dependent. The “read” set and the "write” of the transaction arc stored into 
the appropriate lists. Thus one or more size-un-controlled segments will be 
present in parallel between F) and the last affected segment. Each size-un- 
controlled segment will have its own read_iiems list and a write Jiems list, 
A pictorial representation of a re-segmented log is shown in Figure 2. 




Figure 2: Log Segments ofier Re-itegmenlafion 



Some segments may be larger or smaller than others depending on how 
many transactions arc present in that segment. Each of the newly formed 
segments Fi , Fs » and F# will contain transactions that arc dependent on one 
another. When an attack is detected, only the segment containing the 
malicious transaction has to be scanned since all affected transactions would 
be present in that segment alone. All other sizc-un-controlled segments can 
be safely avoided. We present an algorithm for log re -segmentation in the 
following section. 

3.3 Algorithm for log re-segmentation during damage 
assessment 

1, Determine the position of the attacking transaction using the iufi_iable. 
Let us assume that the transaction, say Tj, is present in Fi, 

2. Set affected Jiems = write_set( T,); readjtents - read_set(T^. 

3. Start new segment F,’. 

4, For each transaction, say Tj, that appears after the attacking transaction Tj, 
in TjUntil the last transaction in the last affected tuft, say Fj, where j>i 

!f ( affected Jiems A rcad_set( Tj ) ^ ) 
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Add Tj to r,’; Add the write scl of T, to affecied_iiems; Add 
rcad_sct( Tj ) to readjiems. 

Else 

Intersect the write set of Tj with all available read_i!ems list. If 
none are available, start a new sizc*un-controlled“scgmenl, add the 
operations of Tj in the segment, start a new read_iietns list and a 
wriiejtetns list and add the rcad_set and wrile_set of Tj into the 
respective lists. Continue from step 3. 

If the result of all the intersections is a null set 

Start a new sizc*un-controlled“Segmcnt, say T/, and add the 
operations of Tj- 

Start a new reodjiems list and a wriie_iierni list and add the 
read set and the write set of Tj into the respective lists. 

If the result of the intersection is not a null set with only one of 
the segments 

Add the operations of Tj into that segment. 

Update the appropriate readjiems list and the 'wriie_iiems 
list. 

If the result of the intersection is not a null set with more than 
one of the segments 

Merge the segments into one single segment. 

Add the operations of Tj into the merged segment. 

Merge the appropriate readjiems list and write Jiems list 
and add T/s read and write items into the respective lists. 

As it is evident in the above method, there is the risk of having to manage 
a segment that is too large because various segments might get merged to 
form one big segment. Eventually this segment might end up being as big as 
the log itself. In order to avoid this scenario, a new method to segment the 
log in a hybrid manner is proposed. In this approach, pointers are provided 
to link the information flow from one segment to another instead of merging 
the segments together. Thus after subsequent damage assessment on the 
database, the log can pictorially be represented as shown in Figure 3. 




Fiffurt 3: A Newer Method fo Segment the Log in a Hybrid Manner 
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Lcl us consider the segments as shown in Figure 1. Assume that an 
attack was detected in fj. As mentioned before, none of the transactions that 
are present in f| need to be scanned as they are not affected. Damage 
assessment is carried out as mentioned before and all the cases hold true here 
too. Let us assume that the first set of parallel segments are formed and they 
are named as Tj, Ty and T4. During subsequent scanning of transactions 
from other size-controlled segments, it is assumed that a transaction read 
data items that were written by transactions from two different size-un- 
controlled segments making that transaction dependent on two different 
segments. From Figure 3. it is evident that a transaction present in P 5 read 
data items written by transactions in Vy and Pj , Thus pointers are 
established from these two segments to Ts to show that there is an 
information flow from both Ty and P? onto Ps . Thus during subsequent 
damage assessment procedures, the pointers can be checked and the 
information flow can be obtained. An algorithm to segment the log using 
the new hybrid log segmentation approach is given below. 

3.4 Algorithm for log re-segmentation using the new 
method of hybrid log segmentation 

1, Determine the tuft, say Tty where attacking transaction, say Tj, i^> present. 

2, Set affectedjiems = write_set(Ti); read_iiems = read_set(Tj); Start new 
segment Pj\ 

3, For each transaction, say Tj, that appears after the attacking transaction Tj, 
in Pi until the last transaction in the la.st affected lufi, say Pj, where] > i 

If ( affecud_items rs read_set( Tj) 1= tJ) 

Add Tj to Pi*; Add the write set of Tj to affecied_iiems\ Add 
read_sct( Tj ) to readjiems. 

Else 

Intersect the write set of Tj with all available readjiems list. 

If none are available, start a new size-un-controlled-segment. add 
the operations of Tj in the segment, start a new readjiems list and 
a wriiejiems list and add the rcad_set and write_set of Tj into the 
respective lists. Continue from step 3. 

If the result of all the intersections is a null set 

Start a new size-un-controlled-segmcnt. say Pj', and add the 
operations ofT|. 

Start a new readjiems list and a wriiejiems list and add the 
read set and the write set of Tj into the respective lists. 

If the result of the intersection is not a null set with only one of 
the segments 

Add the operations of Tjinto that segment. 




24 



DATA AND APPUCATlONfi SECURITY XVll 



Update the appropriate read_items list and the wri{e_i{ems list. 
Iflhc result of the intersection is not a null set with more than one 
of the segments 

Establish pointers between the two segments. 

Retain the read_iiems list and wriie_iiems list as it is. 



4. Damage Assessment Using the Re-Segmented Log File 

There are two ca.scs to consider during damage assessment process when 
an attack is detected after re -segmentation. They arc explained based on the 
segments shown in Figure 3, 

4.1 An attack is detected in F| or in any of the size- 
controlled segments that were ignored when damage 
assessment was done the first time 

The operations of all the transactions from the point of attack in Fi until 
the point where the size-un-controlled segments start arc scanned. The 
“write" set of the first malicious transaction in T\ is added to the 
affecied_items list. The affected_items list is then intersected with the “read" 
set of transactions that appear after the malicious transaction in all the tufts 
until the size-un-controllcd-scgments start. The log gets re-segmented with 
all dependent transactions in one segment. Cases similar to those described 
in the previous section hold good here too. Thus new sets of parallel size- 
un-controlled segments arc formed. Dependency between each of the newly 
formed size-un-controllcd-segmcnts and the existing size-un-controllcd 
segments is then established. It has to be noted that the segments will not be 
merged as described in the previous section. Instead, pointers will be 
established to determine information flow. An algorithm to a.ssess damage 
for the case discussed is given below. 

4.1.1 Algorithm for damage assessment for the case described above 

1. Let the first attacking transaction in F| be T|. Add the writc_set ofTj to 
the affected_iiems list. Start a new size-un-eontrolled-scgmcnt, say TC 
and add the operations of T,in f|’. 

2, For every transaction that appears after T„ say Tj, until the last transaction 
before the size-un-control led- segment starts, do 

If ( affeciedjiems n rcad_set( Tj ) != ^ ) 

Add write_set(Tj) to affecied_iiems\ Add the operations of Tjto Ti’. 
Else 
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Intersect the rcad_scl of Tj with all available readjieins lists that 
were formed for the newly created size-un-eontrolled- segments. 

If none arc available, start a new size-un-controlled- segment and add 
the operations ofTj to that segment. Start new read_items list and 
write _iie ms list and update them aecordingly. 

If the result of all the intersections is a null set 

Start a new size-un-controlled-segment and add the operations 
ofTj. 

Start a new read_items list and a write _items list and add the 
read set and the write set of Tj into the respeetive lists. 

If the result of the intersection is not a null set with only one of 
the segments 

Add the operations of Tj into that segment. 

Update the appropriate read_iiems list ajid the write_items list. 
If the result of the intersection is not a null set with more than one 
of the segments 

Establish appropriate pointers between segments. 

Record the “read" items and the "write” items in the 
appropriate lists. 

4.2 An attack is detected in any of the size«un-controlled 
segments 

In this case, all the size-controlled segments that appear prior to the 
segment in consideration and all other sizc-un-controllcd-segments that were 
formed with the current segment can be safely ignored, as there would be 
definitely no dependency between those segments. Thus, the damage 
assessment process begins by scanning each transaction after the first 
malicious transaction in the current segment. This is followed checking 
every sizc-controlled-scgment and size-un-controlled-segmcnt that appears 
after the first scanned segment until the last affected segment in the log flic. 
With the help of pointers from one segment to another, we can determine the 
information flow and thus know what segments need to be scanned after the 
current one. If there are pointers from a segment leading to two different 
segments, both the segments have to be scanned after the current segment is 
scanned. Similarly, if two different pointers from two different segments 
lead to one single segment, then that segment must be scanned twice while 
assessing damage. If the result is not a null set, it means that segment is 
affected and one or more transactions in that segment have read a data item 
that was previously written by a malicious or affected transaction. An 
algorithm for this ca.se is presented below. 
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4.2.1 Algorithm for damage assessment for the case described above 

1. Identify the sizc*un-conlrollcd-scgmcnt where the malicious transaction 
is present. Let us assume it is V,\ All other size-un*controlled“Scgmcnts 
parallel to Fi* can be ignored. Identify the malicious transaction, say T„ 

in r,. 

2. Append the writc_sct of Tj and all other transactions in the same 
segment to the affected_iiems list. 

3. For each segment, say Fj, that appears after the current segment until the 
last affected segment, do 

If ( affected Jtems r> read_iiems{ Fj ) != ) 

If Fj is a size*un-controlled segment 
Merge Fj’and Fj. 

Merge the respective re ad Jtems list and writejiems list. 
Append the write Jtems list to the affeciedjtems list. 

If Fj is a size*eontrolled“segment then for each transaction, say Th 
inF, 

If ( affeciedjtems r\ readjiemsi Tti )«= 4*^ 

Append operations ofTjitoFi’. 

Append the read_set and write_set of Tj. to appropriate 
read Jtems list and write Jtems list. 

Else 

Intersect the read_set of Tu with all available wriiejtems 
lists of size*un-controlIed-segments that were recently 
created. 

If the result of the all the intersections is a null set or if no 
size- uncontrolled -segments were recently formed 

Create a new size-un-controlled segment with the 
operadons of Tii in it. 

Start a new readjtems list and a wriiejtems list and 
add the read_set and write_set of to the appropriate 
list. 

If the result of the intersection is not a null set with only one 
segment 

Append the operations of Tk and its read_set and 
writc_set to the segment, the readjiems list and 
writejiems list respectively. 

If the result of the intersection is not a null set with more 
than one segment 

Establish pointers between the appropriate segments. 
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In ihc case when an attack is detected in any of the sizc-conliollcd- 
segments that appears after all the si ze-un -controlled segments, the scenario 
is similar to that dcscribcMd in section 3. 



5. Simulation and Results 

A "C“ program was developed to simulate a database log file that 
conforms to the rigorous two- phase locking protocol. The log was 
segmented using the fixed number of transactions approach with 50 
transactions in each tuft. The algorithms developed in this research were 
then implemented into a program and applied on the segmented log file. 
Table 1 shows some of the parameters used to draw the chart depicted in 
Figure 4. 



Table /. Values of Farameters for Chart Shown in Figure 4 



Total number of transactions 


500 


Total number of data items 


5000 


Maximum data items accessed bv a transaction 


30 



The values obtained under the "traditional approach" legend were 
determined by assuming an attacking transaction having transaction Id 150. 
and then determining how many bytes of data arc read from the log while 
performing damage assessment without having a segmented log. The 
"number" legend shows the number of bytes read from a log segmented 
based on the number of transactions and assuming an attacking transaction 
with transaction id 150 too. The third legend, which is "Hybrid 1", shows 
the number of bytes read from a log which was re- segmented based on the 
hybrid approach presented in this research. An attacker was assumed and 
damage assessment was done once and a log segmented based on the hybrid 
approach was obtained. With this log, and the same attacking transaction, 
the algorithm was implemented again but the log was not segmented as it is 
proposed in this research. The number of bytes read was determined. This 
process was carried out several times by changing the seed of the program 
thus obtaining a new log file. An average of all the runs was calculated and 
the chart was obtained. 
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Hybrid Log Sog me station 




Figure 4: Comparison of Various Cktmage Assessmertt Procedures tvifh ihe Hybrid Approach 
Using the Values Shown in Table I 



“Hybrid 2" shows the number of bytes read by the damage assessment 
prograjn when il was implemented as proposed in this research. An 
attacking transaction with transaction id 50, was assumed to be stored in a 
log that is segmented based on the number of transactions. Datnagc 
assessment was performed and a log segmented based on the hybrid 
approach was obtained. With this log as reference, four different attacking 
transactions with ids 150. 250, 350 and 450 were assumed. Each time an 
attack was assumed, datnage assessment was done and while doing so. the 
log was rc ‘Segmented based on transaction dependency using the pointer 
method that was discussed earlier. An average of all the runs was taken. 
Subsequently, attackers 150, 250, 350 and 450 were assumed and each time 
the same procedure was carried out. A different log was obtained each time 
by changing the seed in the program. Figure 5. shows a graph obtained 
using parameters given in Table 2, 



Table 2* Values of Parameters for Chart Shown in Figure S 



Total number of transactions 


500 


Total number of data items 


5000 


Maximum data items accessed bv a transaction 


40 
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Figure 5: Comparison of Various Damage Assessment Procedures H’jVA the H\brid Approach 
Using the Values Shown in Table 2 



6. Conclusion 

In this research, we have presented methods of re- segmenting an already 
segmented log based on transaction dependency for much faster damage 
assessment and hence recovery. We have overcome the shortcomings of the 
previous work where we observed that damage assessment would be more 
time consuming when compared to other log segmentation approaches like 
transaction dependency and data dependency while still being much faster 
had there been no segmentation at all. The model that we have presented 
here will work best in scenarios where attacks are more frequent. The 
segmented log will be re- segmented again based on transaction dependency 
thus limiting damage to only one segment. The process of re-segmenting is 
done while performing damage assessment and thus system resources will 
not be wasted. Different cases were observed while re-segmendng and 
assessing damage using the re-segmented log. Each case was discussed in 
detail and algorithms were provided to handle the cases separately. The 
algorithms were implemented in a simulation model and the results were 
discussed. It was also shown that our model performs better during damage 
assessment than when the log is not segmented at all or when the log is 
segmented using number of transactions. The model is also expected to 
perform similarly well on a log segmented based on either time or space. 





30 



DATA AND APPUCATIONS SECURITY XVU 



Acknowledgement 

This work has been supported in part by US AFOSR under grant 
F49620-01- 10346. The authors arc thankful to Dr. Robert. L. Hcrklotz for 
his support, which made this work possible. 



References 

[1] P, Amman, S. Jajodia, C. D. McCollum, and B. Blaustcin, Surviving 
Information Warfare Attacks on Databases. Proceedings of the 1997 
IEEE Symposium on Security and Privacy, May 1997. 

[2] P.A. Bernstein. V. Hadzilacos. and N. Goodman. Concurrency Control 
and Recovery in Database Systems, Addis on- Wesley, 1987. 

[3] R. Elmasri and S. B. Navathc, Fundamentals of Database Systems. 
Third Edition, Addison-Weslcy. 2000, 

[4] S, Jajodia, C. D. McCollum, and P. Amman, Trusted Recovery. 
Communications of the ACM. 42(7). pp, 71-75, July 1999, 

[5] H. F. Korth, A. Silbcrschatz. and S, Sudarshan, Database System 
Concepts, ThirdEdition, McGraw-Hill International Edition. 1997 

[6] P. Liu. P, Ammann, and S. Jajodia, Rewriting Histories: Recovering 
from Malicious Transactions, Distributed and Parallel Databases. 8(1). 
pp. 7-40, January 2000. 

[7] P, Liu and X. Hao, Efficient Damage Assessment and Repair in 
Resilient Distributed Database Systems, Proceedings of the ISth 
Annual IFIP WG 1 1.3 Conference on Database and Application 
Security, July 2001. 

[8J B. Panda and S, Patnaik. A Recovery Model for Defensive Infonnation 
Warfare. Proceedings of the ^ International Conference on 
Management of Data. p. 359-368, Hyderabad, India. December 1998. 

[9] B, Panda and J, Giordano. Reconstructing the Database After 
Electronic Attacks. Database Security XII: Status and Prospects, S. 
Jajodia (editor), Kluwer Academic Publishers, 1999. 

110| B. Panda and S. Tripathy. Data Dependency Logging for Defensive 
Information Warfare, Proceedings of the 2000 ACM Symposium on 
Applied Computing, p, 361 - 365, Como. Italy, March 2(K)0. 

1 11] P. Ragothaman. and B. Panda. Modeling and Analyzing Transaction 
Logging Protocols for Effective Damage Assessment. Research 
Directions in Data and Applications Security. E. Gudes and S. Shenoi 
(editors). Kluwer Academic Publishers. 2003. 




II 



INFORMATION ASSURANCE 
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SYSTEMS* 
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Abstract Current daiabai^e survivabihty technologies focus on mainiaining data iniegriiy 
and availabi lily in the face ofaiiacks. They are very limiied in satisfying differ* 
eniiated information assurance requirements of various database services under 
sustained attacks. This paper lakes the first steps towards delivering database ser* 
vices with information assurance guarantees. In particular, (a) we introduce the 
concept of Quality of Integrity Assurance(QolA) services; (b) we present a data 
integrity nvodel which allows customers or applications to quantitatively specify 
their integrity requirements on the services that they want the database system 
to deliver: and (c) we pre.sent an algorithm that can enable a database system to 
deliver a set ofQ\>lA services without violating the integrity requirements spec* 
ified by the customers on the set of services. Our approach can deliver integrity 
guarantees to database services, though sometimes some availability loss could 
be caused Our approach can be easily integrated into our Intrusion Tolerant 
Database System! ITDB). 

Keywords: Database Security, Survivability, QolA Services 

1. Introduction 

Despite auihcnticalion and access control, data contained in a database can 
be corrupted by authorized insiders due to operational mistakes or malicious 
intent, or by outside attackers who have assumed an insider's identity. Al- 
though substantial research is done on how to survive data corruption attacks 
[10, 3. 2, 8, 5. 7], with a focus on maintaining data integrity and availability 
in the face of attacks (i.c,. survivability), existing database sur- 

vivability technologies are very limited in satisfying differentiated information 
assurance requirements of various database services under sustained attacks. 



•This work H supported by NSFCCR-TC-0233324, and by the Defense Advanced Research Projects Agency 
(DARPA) and Air Force Research Laboraloiy, Air Force Material Command, US AF. under agreement number 
F20ft02-02- 1-0216. 
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Figure 1. A Survivable Database System Architecture 

We call database services associated with a specific level of information as- 
surance requirements a QolA (Quality of Information Assurance) service. Wc 
say a QolA service is dehverediiihc assurance requirements of the service arc 
satisfied when the service is executed. 

The concept of QolA services is closely related to the concept of database 
irusiworikiness (or assurance), which has two important aspects: one is the ex- 
tent to which we trust that the database stole is valid and not corrupted. Wc call 
this aspect sw/e irusiworthiness, which is the focus of state- oriented survivabil- 
ity. The other is the extent to which we trust that the services delivered by the 
database system are not corrupted or distorted. We call this aspect service trust- 
worthiness, which concerns the database system's capacity in delivering QolA 
services. State trustworthiness represents the System Security Officer's(SSO's) 
view of the database’s trustworthiness, while service trustworthiness represents 
the services’ or the users’ view of the database’s trustworthiness. Service trust- 
worthiness is very desirable because it directly addresses how users' businesses 
are affected by attacks. The goal of this paper is to develop a novel service- 
oriented survivability scheme that can deliver QolA database services. 

The need to deliver QolA services can be further justified by a fundamental 
limitation of a survivable database system we have developed recently, called 
ITDB [9. 2. 8, 7]. The ITDB architecture is shown in Figure 1. When a malicious 
transaction Di is detected, ITDB can locate every transaction affected by 2?, 
(via damage assessment) and repair each corrupted data object without stopping 
the execution of new transactions on- the- fly. However, in many cases damage 
assessment and repair could be slower than damage spreading so the database 
can become even worse (in terms of integrity) during on-the-fly repair. The 
inability of damage assessment and repair in healing the database on-the-fly 
indicates the utility of multiphase damage confinement |7], which will first 
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quickly confine every data object that could have been corrupted as soon as 
a malicious transaction Bi is identified during the confining phase, then try 
to unconfinc the data objects that arc actually not corrupted but mistakenly 
confined during several unconfining phases. To ensure that no new transaction 
will spread the damage (by B|) after Bi is detected. ITDB docs not allow any 
access to a confined data object. 

A serious limitation of multiphase damage confinement is that substantial 
availability could be lost. Since the confining phase needs to instantly confine 
every data object corrupted by Bi, there is no time for the confining phase to 
precisely locate the set of corrupted data objects, so a lot of data objects can 
be jnistakenly confined, especially when the detection latency is long. Thus 
during the repair time window frojn the time when Bi is identified to the time 
when every object corrupted by B* is repaired, many database services which 
need to access a confined object could be denied or delayed. 

Therefore, to provide more availability, it can be very beneficial to continue 
delivering services that need to access a confined data object during the repair 
time window. However, since a confined data object could have been corrupted, 
so when a service of a user Alice wants to access a confined object she takes 
the risk that the service could be distorted, and the SSO takes the risk that the 
service could spread the damage. It is not surprising that whether we should take 
the risks is dependent on whether we can satisfy the QolA requirements of Alice 
on the service. If Alice’s QoIA requirements can be satisfied, then Alice's risk 
is removed, and the SSO’s risk can be compensated by the availability gain. 
Moreover, to minimize the SSO's risk, the SSO can extend the confinement 
control to cover the data objects updated by a QolA service. 

The discussion above indicates the need to deliver QolA services. To develop 
a survivabic database system that can deliver QolA services, we jnust solve three 
fundamental probletns: (a) How can we jnodcl data objects’ integrity levels? 
How can we quantitatively a.s.scss or estimate data objects' integrity levels? (b) 
What is '‘QolA”? How can we specify QolA requircjnents? (c) How to deliver 
QolA services? In this paper, we take the first steps towards solving these 
problems. 

The rest of the paper is organized as follows. In Section 2, we present a data 
object integrity model that allows us to specify QolA requirements. We propose 
a set of valuable strategics to satisfy users’ QolA requirements in Section 3. 
In Section 4, we present an algorithm to allow a survivabic database system to 
deliver services with integrity guarantees. The related work is summarized in 
5, We conclude the paper in Section 6. 
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2. Modeling QolA Requirements In an ITDB System 

In ihis section, we will formally model several aspects ofquani it alive QolA 
specification. First, wc will define some basic terms. 

A database is a set of data objects (objects for short). It is denoted as: 
DB “ {oi, 05 , . . . ,On}« A database provides a set of services to its users. A 
service is a set of database transactions (transactions for short). Il is denoted as: 
5 j= {TipTi, . . . ,7*}. In this paper, we will simplify the service definition, 
and assume that each service just includes one transaction, A user is a business 
customer who accesses the database and changes the database state through 
services, 

2.1. Tlie Model of Integrity of Data Objects 

In ITDB, when attacks occur, some data objects will be corrupted. We define 
integrity in a way different from integrity constraints. In our paper, integrity 
means whether data objects arc goad or corrupted. 

An Intuitive Model of Integrity of Data Objects. Intuitively, we can model 
Ihe integrity of data objects as the following: a data object is associated with an 
integrity value, which is cither of two values: G ox B. G means that the data 
object is good, and B means that the data object is corrupted. The integrity 
variable l{Oyi) is defined for an object 0 al lime t, and l(Oyt) € (G, B }. This 
variable can capture all information of one data object’s integrity property. 

However, in a real ITDB system, the previous model is not practical, because 
it assumes lhal the system knows which objects arc corrupted and which arc 
nol at every point of time, bul it is almost impossible for the ITDB system or 
a SSO to have that knowledge. Wc will analyze the survivability process from 
attack detection to damage repair to show why this is almost impossible. 

Figure 2 shows Ihc confinement timeline and the database stale Iransilion 
diagram when one malicious transaction occurs in an ITDB system. A malicious 
Iransactio n B% starts al li me commi t s at time Tmalx- At lintc ♦ 

ITDB detects that this transaction is malicious, and starts Ihe process ofdatnage 
confinement, damage assessment and damage repair. This process continues 
until time Trepair when every object corrupted by Bi is repaired. We denote 
the period of time from ^detect ^he detection time window, and 

denote the period of time from ibe repair time window. 

In this process, the database has three distinct states. Before time 
data objects in the database arc good, which is stale S\. Within the detection 
time window, some data objects are corrupted by the malicious transaction. 
Since Ihc malicious transaction is not identified by the ITDB system, ITDB still 
regards all the data objects as good objects. This is stale 52, Within Ihc repair 
time window, ITDB has dclecled Ihc malicious transaction. Here we assume 
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Figure 2. The Confine mem Timeline and Data Objects State Transition Diagram for One 
Malicious Transaction 

that ITDB first confines every object that is cither in write set or written 
after time other transactions, and then deny new transactions’ access 

to the data objects in the containment set (In ITDB, after the confining phase is 
done, all the objects that arc confined arc conceptually held in this set). Then 
the database is in state S3. After time the database transits back to state 

SI. 

In state S3, there are four kinds of data objects from the ITDB's perspective: 
( 1 ) Good data: the data objects outside ofthc containment set. (2) Unknown 
bad data: the data objects in the containment set that have been corrupted, but 
ITDB doesn't know that they are corrupted, (3) Unknown good data: the data 
objects in the containment set that have not been corrupted, and ITDB is not 
sure that they are good. (4) Known bad data: the data objects in the containment 
set that have been corrupted, and ITDB knows that they are corrupted. 

From the above analysis, we can find that the above data integrity model is 
not practical, since the assumption is not true in a real system that the system 
knows each data object’s exact integrity value in any time. Thus we need to 
give a more practical model to data object integrity. 

In this paper, we focus on the model and specification aspects about how to 
access the confined data objects in state 53. How to deliver QoIA service in 
state 52 is out of the scope of this paper. 

A Practical Model of Integrity of Data Objects. From the previous analysis, 
we find that ITDB has incomplete knowledge about integrity values of many 
data objects in the containment set within the repair time window. Because of 
this uncertainty, if users arc provided services in this period, they may have to 
take risk of accessing corrupted data objects. Our idea is to use a probability 
based integrity model to quantitatively assess this risk. 

In this model, each data object has also two integrity values; which are G or 
B. G means that the data object is good, and B means that the data objects is 
corrupted. 

In order to assess the risk, we have to estimate which data objects arc good 
in the containment set. since we can not get exact information about it. Assume 
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that we have a gocxl estimator to estimate probabilities that data objects in the 
containment set arc good in the repair time window. (In the later section, we 
will have a more detailed discussion about how to do estimation.) We denote 
the probability that a data object Oi is goodattimet as Wecall G{oi, <) 

as Oi*Siniegriiy level, and 0 < < 1. Integrity level of a data object a 

indicates that the frequency ofo, is good when a specific attack pattern occurs. 
For example, when a malicious transaction Be occurs, » 90%, which 

means that if the bad transaction Bq occurs 100 times, the limes when o, is 
good is 90. 

For example, for an objectojvhen ihe database is in states 51 or 52, 
G{Oi t) = 100%. When a malicious transaction is detecled at lime 
G(o, f) is estimated as 40%, At lime 0 is identified as damaged, then 

G(o> t) = 0%. In the time ^ repaired, so G(o, t) is updated to 100% 

again. Thus o's integrity level is: 



G(o.t) = 



100% t<Ta,^aOfT>T?^ 

40% ^ ^ < ^Xenit/y 

0 % TtunU/v ^ 



This model is more practical than that of the intuitive model, since in many 
cases We can use the (transaction) history to gel good estimations about data 
object integrity levels, and moreover the SSO can use additional semantic in- 
formation and workload characteristics lo improve such estimations. Finally, it 
should be noted that the intuitive integrity level model is a special case of this 
model. If at each time t, we let G(o, f) have only two values; 100% or 0%, 
then this model will generate the same kind of integrity levels as the intuitive 
model. 



2.2. The QoIA Requirement Model 

Based on the data object integrity model, we can specify QolA requirements. 
For each user, his/her QoIA requircmenls are the requirements on service trust- 
worthiness. Since a service is composed of a set of transactions, to specify 
QoIA requircmenls, we need to model a transaction's trustworthiness at first, 
A transaction's input and output arc shown in Figure 3. A transaction (a) has 
a set of input arguments, called the w;?Mroflhc transaction, (b) reads a set of 
data objects, called the readsei of the transaction, and (c) writes a set of data 
objects, called the wriiesei of the transaction. We denote a transaction Ts input 
os It, its readset as writeset as Wt- 

We assume that the input to a transaction is not corrupted and the execution 
of the transaction is not distorted. Hence, the transaction's trustworthiness is 
only related to its readset. How to handle malicious inputs is out of the scope 
of this paper. 
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Figure 3, A Transaction's Input and Outpul Graph 

Transaction T's QolA requirements: for a data object Oi in F’s readset, a 
lowest bound of integrity level is specified and denoted as th{o^,T)y where 
ol € Rt- This requirement means G(oJ’,7') > at any time. 

Next we will define a useru’s QolA requirements: fora service Sk 
uses, the QolA requirements of u on S'* are specified for each transaction that 
belongs to this service. In particular, a lowest bound of integrity level for each 
transaction Tj that belong to S* is specified, Wc denote it as th{o\^Tj, Sk)* 
and this requirement means that S*) > th{d[,Tj, Sk) should be held 

at any time, in which oj € Rxy 

In our framework, can be specified by users or by an agent 

program. The jnechanism to specify it will be our future work. Now we have 
specified a user’s QolA requirements. The next issues are how ITDB systems 
can satisfy all users' QolA requirements, and what strategies ean be used to 
deliver QolA services. 

3. Strategies to Satisfy Users’ QolA Requirements 
3.1. How to Estimate Data Objects’ Integrity Level? 

When a malicious transacdon Bi is conunitted, the objects in arc the 
initial corrupted data objects. And then in the detection tijnc window, the 
corruption will be spreading to other data objects through the new transactions’ 
execution. This spreading is related to Wb^ 2 nd new transactions’ anival pattern 
and access pattern, thus wc can use previous history to predict the future. The 
idea is to do prediction based on a probabilistic object affecting pattern. For 
each object o*, we can use the previous history to estijnatc the probability that 
another object Oy is affected by Cj , directly or indirectly . Then we can construct 
an affected object set forc>*. This set includes every object that can be affected 
by Og and the probability that this object is good when Og is corrupted by a 
malicious transactions B (Og € For example, the affected object set can 
be as the following: {(oj.pi), (o,,p,), , . . , (o„,p„)}. o^, 1 < j < n is the 
data object that has been affected by o* in the history, and py is the probability 
estimation that oy is good when Oi is corrupted by a malicious transaction. 
When a malicious transaction B is detected, we can check the affected object 
set of the data objects that belong to Wq. For example, suppose B'% writeset 
Wb ~ {of. of. ... , o" }, the affected object set of of is ^(of ), 1 < i < n. 
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If a data object o belongs to affected sets ^(o{^), - . . , /l{o}J'), and its 

tuples arc (o,p„ ), i < ii.is, . < m, wc can set 

G{o,t) = . i is time from current time until the ITDB 

identifies whether o is good. 

3.2. How Can Transactions AtTect Data Objects’ Integrity 
Levels? 

First, we want to present the propagation rule. 

Propagation rule; if transaction T's read set is ^m)» 

then for each data object € Wf, its integrity level = 

mtn{(?K),G(o5) G«)}. 

The propagation rule is a syntactic rule, and it produces conservative results. 
If we use semantic analysis, for example, data flow analysis, we can get more 
accurate and optimistic results. The issue to do semantic analysis is out of the 
scope of this paper. 

Not all transactions propagate damage (caused by a malicious transaction). 
We call the transactions that propagate damage as spreading transactions. 

Spreading iransaciion: During a repair time window, if a new transaction's 
readset includes some data in the current containment set, and the write set is 
not empty, it is called a spreading transaction. 

The other transactions are non-spreading transactions. They include read- 
only transactions and the transactions that don’t access objects in a containment 
set. 

Spreading transactions can spread corruption to new data objects (when data 
objects in their write sets are out of the containment set) or increase data objects’ 
corruption probability (when data objects in their writesets are in the contain- 
ment set). This will affect the capability of the ITDB to satisfy all users’ QoIA 
requirements, 

3.3. Strategies in Making Decisions about Denying a 
Spreading Transaction 

Within a repair time window, if a spreading transaction comes, a decision has 
to be made about whether to deny its execution or not. Consider the following 
objectives when making such a decision. 

■ Throughput rule: execute as many transactions as possible that access 
objects in the containment set, 

■ Spreading rate rule: guarantee that the damage spreading rate is low. 
The damage spreading rate can be defined in several ways, for example, 
it can be measured by the number of data objects newly corrupted within 
one second. 
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The ihroughpul rule aims lo maximize ITDB’s availability in delivering QolA 
services. In conlrasl. the spreading rale rule aims to (a) minimize the amounl of 
damage spreading that could be caused by ihe QoIA services that access a con- 
fined data object, and (b) minimize the number of services that need to be undone 
later. Note that ifa transaction allowed to access a confined data object is found 
affected and involved in spreading the damage, it will be undone, and the user 
that submits the service will finally lose the availability of this service. In the fol- 
lowing. we will use an example to show the idea. Suppose when an ITDB system 
detects a malicious transaction B. it will enforce the initial confinement instantly 
and the resulted containment set is Co* For an object o € Co, suppose before o is 
repaired, a sequence of transactions will arrive at the ITDB system and ask to ac- 
cess o, Suppose these transactions arc: (Ti,0.9), (T2,0.6.0,6). ( 73 , 0,8.0. 8),- 
(T4,0.9), (T 5 , 0.8, 0.8). (T$,0.7.0.7), (T7,0.9). Thctuple (Ti, 0.9) means that 
T\ will not write to c>(i.c„ it is a read-only transaction), and its requirement on 
o*s integrity level is 0,9, The tuple (Tg, 0.7, 0,7) means that (a) Tg will write 
to o; (b) Tg’s requirement on o*S integrity level is 0.7; (c) Tg will change o’s 
integrity level to 0.7 after Tg commits; and (d) Tg’s writeset includes only o. 
Other tuples have similar meanings. 

When T\ arrives, we assess and found that o’s integrity level is 0.9. For 
this sequence, we can do an offline analysis based on the cojnplctc knowledge 
about what transactions will arrive following T\ to get an optimal execution 
sequence that enforces the two rules. With the constraint that a transaction 
can be executed only if its QolA requirements can be satisfied, the following 
execution sequences are possible: ( 1) Ti, Tg; (2) Tj, Ts. T$; (3) Tj, T 4 . Ts, 
7$; (4) Ti, T 4 , Tf. According to the throughput rule and the spreading rule, we 
can find the optitnal execution sequence is sequence (3). 

The above example handles only one object. For multiple objects, similar 
offline analysis can be done. With offline analysis, we can make optimal de- 
cisions in terms of the two rules about whether or not to deny a QolA service. 
However, in the real world, in many cases we have to make such decisions on- 
line without complete knowledge about the transactions that will arrive in the 
future. The decision is related lo the future transactions' arrival patterns and 
access patterns, and also related to their readscls and writeseLs. It is clear lhal 
without complete knowledge about these affecting factors, it is impossible lo 
make optimal decisions when delivering QolA services. Hence, from now on, 
we will focus on ncar-oplimal decision making using heuristics. In particular, 
we want to use the history to do some predictions about what could happen in 
the future, then make decisions based on the prediction. The prediction is basd 
on some heuristics. We propose a simple method to deal with this problem: 

• First, in order lo enforce the spreading rate rule, we set a lowest bound or 
threshold for the integrity levels of all the data objects in the containment 
set. We denote this threshold as Go* example, if we set Go = 70%, 
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then for each object o in the conlainment set, G(o) > 70% should be 
always satisfied. 

• We want to use the history to judge if we will let a spreading transaction 
be executed. Our simple scheme is based on the following heuristic; if 
there are a lot of new spreading transactions arriving, then there will be 
many similar type transactions bound to arrive later. Our idea is that 
if there arc at least DENY_SIZE spreading transaetions that have been 
denied, this kind of spreading transaetions will be pennitted to execute 
next time if the QoIA requirement is satisfied and the lowest threshold 
Gq is satisfied. DENY_S1ZE is a parameter to speeify the number of 
spreading transactions that the ITDB can deny execution at most. For 
example, in the previous example, if we set DENY_SIZE= 2, then the 
execution sequence will be Ti, Ts, T 5 , DENY_SlZEcan be adjusted 
according to previous repair history. 

The above is only an example heuristic based method. Good heuristics need 
to adapt to different workloads. Developing and evaluating new heuristics for 
different situations will be one of our future work. 

4. QolA Aware Damage Conti nement and Repair 
Algorithm 

In this section, a QoIA-awarc damage confinement and repair algorithm 
will be proposed. We only focus on how to integrate our QoIA management 
framework into the original ITDB algorithms [9]. In order to provide QoIA 
services, a new module QoIA manager will be added, and the modules of 
the Confinement Executor, the Unconfinement Executor, which both belong to 
the Damage Confinement Manager, and the Damage Repair will be modified. 
Since QoIA services may spread the damage, for spreading transactions, we 
will confine objects of their writesets to control probably damage spreading. 

4.1. Data Structures 

In the ITDB, each object is associated with a lime stamp, denoted by tSx~ 
t&x indicates when x is updated. The ITDB's log includes all read and write 
operations of the transactions. (Refer to the paper [9] about the techniques for 
getting read information,) ITDB maintains D_SET and U_SET that arc used in 
the damage containment and repair stage. D_SET maintains each object that 
the Damage Repair has identified it corrupted, and U_SET maintains the set of 
objects that have been unconfined by the Unconfinement Executor. And ITDB 
uses the confinement lime window to enforce time stamp based confinement 
control. 

In this algorithm, we will add three new data structures: 
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■ STT: a spreading transaction tabic that is an array of records. Each record 
has six fields: (1) a transaction id; (2) a start time of this transaction; (3) 
the commit time of this transaction; (4) a transaction type (used by the 
type based unconflncment phase [7]); (5) a list of input arguments of 
this transaction (used to materialize a transaction’s readset and writeset 
P])* (6) a log sequence number of this transaction’s commit record in the 
log file (used to find all the operations of this transaction, since all the 
operation log entries of a transaction arc chained together in the log). STT 
records each spreading transaction’s information in the repair period. 

■ l_SET: an anay of tuple (o, G(o))» G(o) is o's integrity level. After 
the Qo!A manager assesses an object' integrity level, we put the tuple 
{o,G{o))toI_SET. 

■ S_SET:tm anay of data objects. This array keeps all spreading transac- 
tions' writesets. This set is a new spreading set after initial confinement. 
In order to control damage leakage, we will still contain this set. Thus 
the intersection of S_SET and U_SET is empty, since objects in U_SET 
have been unconflned. 

4.2. QoIA Manager 

The QoIA Manager is a component to stay between the Policy Enforce- 
ment Manager and the Database Schedulcr(refcr to Figure 1). and it maintains 
the global data structure STT and the local data structure I_SET, The Damage 
Confinement Manager and Damage Repairer modules will access STT, 

In the repair time window, when a new transaction arrives, the QoIA Man- 
ager will check if the system can satisfy the QolA requirements of the user who 
submits the transaction. If it makes the decision that this transaction can be 
executed, it forwards this transaction to the scheduler; else, it denies this trans- 
action, and sends a response to the user. Thus the QoIA manager is responsible 
to: (1) Assess an object's integrity level if a new transaction will access this 
object. (2) Evaluate if a new transaction’s QoIA requirement is satisfied, (3) 
Make the decision whether to deny a new transaction or not. (4) Maintain STT, 
I.SET. 

Algorithm I [QoIA Control] 

/* it only executes in the repair period. And the Confinement Executor maintains 
the confinement time window [tl,f2j. For an object o, iftl < fa© £ 

0 i U.SET. or ifo € SJS^fTy then o is confined. *f 
while ( a new transaction T arrives } 

{ 

for each object oj € Rt 

// In the transaction T. c»[’s QoIA requirement is Q(of) 
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if ( 0 ^ is confined) 

if ( oj is in I_SET) retrieve its integrity level as (/{oj*). 
else estimate its integrity level as G(o^» 
and add the tuple {o^, G{oJ*)) in I_SET. 

< Cf(o^) deny this transaction's execution, 
and go to while statement. 

I 

) 

use the strategies proposed in Section 3 to make the decision about 
whether this transaction can be executed. If it is permitted to be executed, 
then the QolA Manager forwards it to the Scheduler.) 

For a spreading transactions after 7a is committed, for each object € 
Wj-gi 2 tuple is added in 1_SET. and of is added in S_SET. Then 

the record of TV is added in STT, and if of € U.SET^ then remove it from 
U_SET. If it is aborted, there is nothing to do, 

4.3. Moditicatioas to the Damage Contlnement Manager 
and the Damage Repairer 

One of the main differences between QolA services and original ITDB scr* 
vices is: in QolA services, Transactions can access confined data, so it can 
spread damage in order to deliver QolA services. We have to modify the Dam* 
age Confinement Manager and Damage Repairer to handle this situation. 

In the Damage Confinement Manager, all transactions that each uncon fine- 
ment phase has to handle include the transactions in the confinement lime win- 
dow (cl, C2J and the transactions in STT. All containment data objects that each 
unconfinement phase has to handle include the objects whose updated lime 
stamps arc within the period of [Cl, C2) and the objects in S_SET. In QolA aware 
situation, the Damage Confinment Manager has to handle more transactions 
and more objects with the similar algorithm with the original one. 

The Damage Repairer has the similar modification as that of the Damage 
Confinement Manager. Besides original transactions and objects that it has to 
handle, il will also handle transactions in STT, and repair corrupted objects in 
S_SET, After an object o is repaired, the Damage Repairer will remove o from 
S_SET ifo € S.SET.and change the confinement time window to [C^^,, f 2), which 
means the log before lime iSc, has been repaired. For a transaction T € STT, 
after T is repaired or identified as good, T will be removed from STT. 

Since the QolA service probably spreads damage, we need lo make sure that 
repair procedure can terminate. It is easy lo detect the repair termination, since 
we only need to check whether STT is empty and the length of confinement 
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lime window is 0. Then Ihc termination problem is: how can wc make sure that 
repair can Icrminatc? 

In our algorithm, we can easily control the damage spreading rate. Wc can 
use sizes of STT and S_SET lo dynamically change the parajneter DENY_SIZE 
and Go (the lowest threshold for all contained obj eels’ integrity level). By 
changing DENY_SIZE and Go* the damage spread rate can be controlled. Thus 
we can make sure that repair can terminate. 

4.4. Pertbrmance Issues 

With the strategics that we proposed previously, it is easy to integrate the 
Algorithm 1 to the ITDB prototype. Through analysis of Algorithm 1, we can 
find thai the algorithm has liitlc impact to the ITDB’s performance. 

In the algorithm, ihrec additional data structures are added. Within ihc re- 
pair time window, the number of spreading transactions is denoted as Nt,- 
assume that a spreading transacdon’s writeset and read objccis in the contain- 
ment SCI are small, then ihe space complexity of all STT, 1_SET. and S_SET is 
0{Nt.). 

The al gorithm is enforced onl y duri ng the repair time wi ndow . li o n ly handl cs 
transaciions thai will access some confined objects. If damage spreads, the 
Damage Confinement Manager and Repairer will have additional work, but we 
can control the damage spreading rate. This is a tradeoff between additional 
repair lime because of damage spreading and the gained availability through 
delivering QoIA services during the repair time window, 

5. Related Work 

With a focus on daia confidcndality. iraditionaJ database security technolo- 
gies. such as authorizaiion [6], inference control [IJ, multilevel secure databases 
1 12], and muldlcvel secure iransaction processing [4], cannot tackle data cor- 
ruption attacks. Allhough database survivability is a relatively new topic, ihcre 
is already substaniial work in this field. Some datj^asc attack recovery work 
is done in (1 1), In [3]. a color scheme for marking damage and a notion of 
integrity suitable for databases ihat are partially damaged arc used to develop a 
fault-toleranl mechanism lo survive database ailacks. Their approach assumes 
that each data object has an (accurate) initial damage mark, while our approach 
will dynamically estimate and adjust the iniegrity levels of a loi of objects 
whenever a new malicious transaciion is identified. 

In [9]. a comprehensive survivable database system (i.e.. ITDB) is devel- 
oped. where several valuable database survivability techniques arc developed, 
such as on-ihe-fly attack recovery [2], attack isolation (8J and multiphase dam- 
age coniainmcnt (7]. However, all ihese techniques focus on how to maintain 
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data inlcgriiy and availability under sustained attacks, and they arc limited in 
delivering QolA services. 

6. Conclusions 

This paper lakes the first steps to deliver database services with informa- 
tion assurance guarantees. In particular, (a) we introduce the concept of QolA 
services; (b) we present a data integrity model which allows customers or appli- 
cations to quantitatively specify their integrity requirements on the services that 
they want the database system to deliver; and (c) we present an algorithm that 
can enable a database system to deliver a set of QolA services without violating 
the integrity requirements specified by the customers on the set of services. 

In our future work, first, we want to develop the efficient strategies to estimate 
data objects’ integrity level; second, we want to extent and generalize our 
integrity model to deal with other situations, such as, the integrity model for 
data objects in state 52; third, we want to implement a prototype to evaluate 
our design. 
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Abstract 

Data integrity can be problemaLic when integrating and organizing 
information from many sources. In (his paper we describe efficient mech* 
anisms (hat enable a group of data owners (o contribute data sets to 
an untrusied third«party publisher, who (hen answers users' queries. 
Kach owner gets a proof from the publisher (hat his data is properly 
represented, and each user gets a proof that the answer given to (hem 
is correct. This allows owners to be confident that their data is be- 
ing pn>perly represented and for users to be confident (hey are getting 
correct answers. We show that a group of data owners can efficiently 
certify that an untrusted third party publisher has computed the cor- 
rect digest of the owners' collected data sets. Users can then verify that 
(he answers (hey get from the publisher are the same as a fully (rusted 
publisher would provide, or detect if they are not. The results presented 
support selection and range queries on multi-attribute data sees and are 
an extension of earlier work on Authentic Publication which assumed 
(hat a single trusted owner certified all of the data. 
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1. Introduction 

Many sellings require dala from multiple sources lo be combined into 
a single online database, A combined data set offers Ihe convenience of a 
single source for queries and support for query types that are dependent 
on the overall data set. These benefits come at the cost of introducing 
new security concerns. Principal among them is the need lo ensure 
the honesty of the party who collects Ihe data and provides answers to 
users' queries. In order to assure accurate answers to queries, we need 
lo prevent inadvertent and malicious dala corruption. 

In this paper we provide a formal framework and specific implemen- 
tations which address the problems that arise when an un trusted third 
parly publisher collects and organizes data from many different dala 
owners and then provides answers to user queries on the combined dala 
set. We focus on achieving the two closely related goals of providing a 
third-party publisher with efficient mechanisms to: 

(1) Assure data owners lhal Iheir dala will be accurately represented 
in answers lo user queries. 

(2) Assure users that the answers to their queries are accurate. 

Motivation and applications. Sites which provide provably accu- 
rate dala have many important applications including consumer, finan- 
cial, medical and government settings. Many of these applications draw 
from multiple sources for Iheir conleni and, as Ihe Internet expands. 
Ihe need for accurate dala will only increase. As data becomes more 
valuable, the motivation for dishonest data representation increases and 
thus Ihe need for mechanisms to prevent il. 

A product pricing engine provides a simple and familiar example 
where a number of dala owners, here retailers, coniribule data lo an 
untrusted publisher, Ihe pricing engine. If a user asks for a list of all 
digital cameras matching a given description, they want lo know that 
they have Ihe cheapest listing and that everything in the list is a legit- 
imate. The retailers also want to be sure that Ihe pricing engine is nol 
excluding or misrepresenting Iheir products in favor of other retailers. 

In this silualion. we want the retailer to be confident that Ihe pricing 
engine is returning all of his products which match the users description. 
More generally, we want a retailer lo be sure that all of his products 
that match the query are relumed to Ihe user. The user also should be 
confident that all of the returned data is from legitimate sources. We 
want lo achieve these goals without forcing a retailer or consumer lo 
spend large amounts of extra resources lo ensure data integrity. 
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Our solutions provide mechanisms to support multi -attribute queries 
which expands the range of database applications. 

Extending authentic Publication. There are many possible ways 
to assure data integrity. Our solutions are an extension of prior work on 
Authentic Publication [6] which allows untrusted third piu'ty publishers 
to provide users with query answers and short proofs that the answer 
given is correct. Merkle trees [13, 14] provided the original basis for this 
work. Since our results extend Authentic Publication to multiple owners, 
we briefly recap the basic construction. Our example uses a binary search 
tree, for a data set D, with the values stored at the leaves. The tree is 
digested using a cryptographic hash function as follows: Starting at the 
leaves, the digest value of a leaf is the hash of its data value. The digest 
value of an internal node is the hash of the digest values of its (two) 
children. The overall digest value of the tree is just the digest value at 
the root. With this digest value, an efficient proof, of size 0(log |D|) can 
be given that a data item is or is not in the set. 

Authentic Publication has this initial setup: (1) A trusted owner di- 
gests the data (e.g. with a binary search tree); (2) the data is given to 
one or more untrusted publishers; (3) the digest is distributed to the 
users. Users now send queries to an untrusted publisher, and the pub- 
lisher returns an answer and a proof that the answer is the same as would 
be given by the trusted owner. Efficient protocols based on the Merkle 
tree approach [6] and general methods for producing them [12] exist for 
a wide range of query types and were proved to be secure in [12] as long 
as the publisher can't fmd a collision in the hash function. This ap- 
proach has many advantages including scalability, since anyone can be a 
publisher, efficiency, since it uses efficient hash computations, and secu- 
rity, since there lU'e no secret keys used in the proofs to be compromised. 

Multiple Owner Setting. We want to extend the advantages of 
Authentic Publication to the multiple owner setting. However, with 
no single trusted source and limited communication among the owners, 
there are new challenges. Now, not only does the publisher need to 
convince the user that the digest used in verification is a valid one, he 
must also convince each owner. One possible solution has the publisher 
give the entire collected data set to each owner, who then computes the 
digest on his own, more or less replicating the single owner Authentic 
Publication protocol. However, each owner must now deal with the 
entire database, and we want each owner's work to depend only on the 
size of his own data set. There are significant difficulties presented by 
this since each owner only sees a part of the data and digest structure 
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being verified. Since the publisher is not trusted, we must also prevent 
him from creating and including his own values in the data set and 
digest. We now give a high level view of our protocols: 

Consider a situation in which a set of n data owners 0j,02, ...,0^ 
wish to combine their respective data sets support 

multiple queries for many users U. Assume that a third party publisher 
P collects and combines the sets, and provides the answers to users' 
queries. The publisher needs to convince each owner that his data set is 
correctly included and each user that her answer is accurate. A typical 
sequence of events is in figure 1 as follows: 




Figure /. Typical proiocol execution. 



1 The owners Ot their data sets D\ to the publisher P. 

2 P collects the data sets and computes a digest S of the combined 

data set D = Ui»i owner, a proof 77* that the 

data set D, is correctly included in 2^. ]7* and 27 are sent to each 
owner, S is also made available to the users. 

3 Each owner evaluates his proof and either accepts or rejects, noti- 
fying any users of this result and the digest value 27. 

4 A user U sends query to P. 

5 P computes an answer ans and a proof a* that ans is correct, re- 
turning these to U. 

6 U evaluates ans and a*, and either accepts or rejects. 

We assume that each owner and user receives the same value for 
whether or not it is accurate. We also assume that every party has ac- 
cess to the hash function H which is used to produce the digest and in 
the verification procedures. With multiple owners, we can either assume 
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that all owners are trusted to complete the protocol, or that some owners 
are untrusled, and may conspire with the publisher or other untrusted 
owners. We outline the results in each case. We will also consider set- 
tings where a trusted third-party collects owner approvals of the digest 
E. This reduces the need for owner-user interactions, and for the user 
to know the details of which owner's contributed to the data set. 

Goals. When an untrusted party collects data for (re)publication there 
i\rc a variety of guarantees users imd data owners might desire. Perhaps 
the strongest is that the answer to any query is exactly the same as would 
have been given by a trusted data collector who correctly acquired the 
owners’ data. In the Trusted owners section below we discuss achieving 
this strong result for multi-attribute queries. 

An important, but weaker goal would be to assure an owner (and 
users) that all his data will be correctly included, but the answer might 
also include bad data from other, or non-existent owners (e.g. for a se- 
lection or range query). An additional goal is to assure the owner that 
no data items not in his data set will be falsely reported as his. We show 
this is possible for a broader range of settings. 

Trusted owners. For a collection of n trusted owners, we provide 
an efficient protocol that an untrusted publisher can use to compute a 
digest value X* for a binary search tree storing the owners' combined 
data set. The publisher provides a proof to each owner, proportional in 
size to each owner’s data set (and the log of the combined set), that Xi^J 
valid. If each owner accepLs their proof, and there is no collision found 
in the hash function, then X is exactly what a fully trusted publisher 
would have produced for the owners' combined data. We achieve this 
using a count certified search tree which we define and use to support 
the protocol. The count certified search tree supports, among other 
query types, authentication of answers to selection and range queries. 
Users can query the Publisher many times based on X, just as in the 
single owner Authentic Publication setting. We also extend this result 
to digests of multi -dimensional range trees which allows a richer set of 
multi-attribute queries (e.g. return all digital cameras which have 1-3 
mega-pixels, cost S250-S400 and weigh at most 6 ounces). The results 
in this setting are given in section 2. 

Untrusted owners. If some owners cannot be trusted to follow the 
protocol, and might be conspiring with the publisher, we still want to 
guarantee each honest owner that if he approves the digest of a publisher, 
then his data will be properly included in answers to queries. As before. 
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each owner gets a proof of size proportional to his individual data set 
(and the log of the entire data set). If an owner approves this proof, then 
he can be confident that any answer a user accepts will contain exactly 
those data items from his data set which satisfy the user's query. This 
works for selection, range, and multi-dimensional range queries (e.g. in 
our digital camera example above, a retailer who approved the digest 
value of a publisher could be confident that all of his cameras which fit 
the user's criteria would be returned). We also provide new, efficient 
mechanisms to prevent false data attribution. An honest owner O can 
be sure that the publisher cannot return a data item which is claimed 
to belong to O, but is not in O's data set. 

1.1. Background and Related Work 

Data authentication has been used for time-stamping [9] and micro- 
payments [4]. The work in this paper is an extension of earlier work on 
Authentic Publication [6j, The techniques used in Authentic Publication 
are based on the original work by Merkle [13, 14) and refinements by Naor 
and Nissim [15] for certificate revocation. 

Devanbu and Stubble bine showed how to create authenticated ver- 
sions of stacks and queues in [7], and Maniatis and Baker [11, 10] present 
similar methods for authenticating B-trees and using them for secure 
data repositories. In [6], we introduced the general idea of authentic 
data publication, and showed how to securely answer a broader range of 
queries. This work is extended to authentic publication of XML docu- 
ments in [5] using authenticated tries, and in [12] we introduced a gen- 
eral model and framework for Authentic Publication for a wide range of 
query types by defining a general class of authenticated data structures. 
Goodrich. Tamassia Triandopoulos and Cohen applied this to a wide 
range of geometric data structures in [8]. 

The above approaches share a common theme of leveraging the trust 
provided by a few digest values from a trusted parly over multiple hashes 
to efficiently protect the integrity of the digested content. All of these 
methods rely on a single trusted owner to compute the digest. Our 
scheme avoids this limitation, but extending these results to a more 
complex distributed setting introduces new challenges to maintaining 
efficient data authentication. Nonetheless, our protocols incur essentially 
the .same computational effort as in the non-distributed setting. 

Two recent papers have started to reduce the need for a single trusted 
data owner. Buldas. Laud and Lipmaa [2] presented a scheme for ac- 
countable certificate management. Though the focus and setting are 
different from ours, they achieve some similar results. They show how 
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an unirasted party can compute a digest of a set of certificates and, for 
a given certificate, prove that it is or is not a member of the set. Using 
an authenticated search tree, they show that unless an adversary finds 
a collision in the hash function, no contradictory proof can be given. 
This is almost the same as our result in the untrusted owner setting de- 
scribed in section 3 for selection queries. Our results, however, describe 
extensions to more complex queries and methods to prevent data which 
is falsely attributed to an owner. In [3], Buldas, R(x>s and Willemson 
provide some detail for a solution to “interval” or single dimensional 
range queries, but do not address the issue of proofs to owners showing 
that data is correctly represented. They describe as an open problem 
the extension of authentication techniques to multi-dimensional range 
trees. We «dve this open problem using a count certified search tree 
which is an enhanced version of their authenticated search tree. Our 
mechanisms guarantee that the untrusted third party has computed the 
digest of a search tree just as a fully trusted party would. This is a 
stronger guarantee which allows a richer range of queries in our setting. 

2. Implementations for Trusted Owners 

Suppose a Publisher wants to collect data from n data owners, store 
this data in a Binary Search Tree (BST) and then compute a digest of 
the data. We present an efficient and secure protocol which allows the n 
owners to determine that the digest computed is the same as the digest 
which would be computed by a trusted party with access to the owners' 
joint data set. We extend this to digests of Multidimensional range trees 
(MDRTs) to efficiently answer multi -attribute queries. 

We assume throughout the paper that all data items d have a value 
key(d) which is unique. It is possible that two data owners may each 
have data items with the same kx;al key values. By adding a unique 
owner identifier to the local key values, the new global key value key(d) 
is again unique. We give a somewhat informal description of our results 
in this section to focus on the main ideas. A more formal treatment 
(along with the proofs) is given in the full version [16]. 

2.1. Owner Certification of a Binary Search Tree 

We consider a setting with n owners with data sets D\ , . . Dfx. We 
let D denote this combined data set and let N be the total number of 
items. For the protocol to produce a correct result, the true value of N 
must be used in the Owner verification. We discuss ways to ensure that 
each Owner knows the correct value of N in section 2.4. 
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Following the protocol outlined in the introduction, our goal is to 
allow an untrusted Publisher who knows D to construct a binary search 
tree and its digest S, then efficiently prove to the owners (using the 
proofs jt‘) that their data is correctly represented in a tree which has 
digest S. Once we establish that the digest S correctly represents D. 
the Publisher can answer queries from users and provide proofs just as 
in single owner Authentic Publication, If all parties follow the protocol 
correctly, then all owners will accept their proofs for E. The following 
theorem states that our Owner BST ceriijicaiion protocol is secure. 

Theorem 1 For a set of n owners with data sets ...Dnf where 
N is the number of data items in D = D,, if each Owner correctly 

executes the BST certification protocol and accepts his proof for the digest 
E <tnd the data count N, then either E is a valid digest of a BST for D, 
or the Publisher has found a collision in the hash function used. 

The Publisher can compute the digest E and all proofs in 0(N log N) 
time, and Owner i can verify his proof in 0(|r),| log/'/) time. 

Thus the verification time for an owner i is nearly linear in the size 
of the set £),, The full details of the proof of Theorem 1 are in the full 
paper [16]. However, the next two subsections, describe the digesting 
scheme and sketch how the publisher proves to the owners that their 
data is correctly represented. 

2.2. The Count Certified Search Tree 

Since each owner only sees a small part of the tree, we need a stronger 
digesting scheme than is used in a standard Merkle tree. A count certified 
search tree is a binary search tree, storing data values at the leaves and 
split values at internal nodes and is digested using the following scheme. 
The count associated with a node v of the tree (denoted count(u)) is the 
number of data items stored in the leaves of the subtree rooted at v. 
We also let split(v) be the split value and digest(u) be the digest value. 
Our digesting scheme uses a collision- resistant hash function H. The 
digest value of a leaf is just the hash of its associated data value. For an 
internal node v with children u and w, 

digest(u) = H(split(v),count(u),cour>t(w),digest(ii),digest(u/)). 

We note that the BST structure is only a logical structure which 
the protocol must use for digesting and proofs. The publisher need 
not physically implement his database this way. For example, prior 
results show that a logical BST can be used with a physical B-tree 
implementation [11. 10, 12]. 
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2.3. Proofs to Owners 

We sketch how the Publisher proves to im owner 0» with data set 
that this data is properly represented. Details are presented in [16]. For 
each data item rfin Dt the Publisher’s proof essentially simulates a search 
for data item d\ the proof is a sequence of five tuples of values followed 
by d. The first five tuple contains the five values used to compute the 
digest value i7 of the root r of the (claimed) BST with left child u and 
right child w: spllt(r), count(u), count(uf), dlgest(u), digest(tc). 

The owner hashes these five values to get a result and rejects unless 
X ss If X = he uses the root's split value to determine if the search 
should go left. d< spht(r), or right, d > split (r). If the seiuch goes left, 
the next five values of a conect proof hash to dig«st(ti), 

This digest value is known from the first five values in the proof Thus 
we can check that the second five values in the proof hash to dlg€8t(u), 
and we am also check that the counts match (the second five values 
should include the number of leaves in the left and right subtrees of ti; 
the sum of these should match count (u), the number of leaves in the 
subtree at u. which was given in the first five values of the proof). 

The verification process continues until, in the final step, we should 
reach a leaf whose value is d and which has an associated count of one. 

In [2. 12) they also use split values to simulate a seiuch however, our 
use of the counts is new. The split values make sure that no data values 
are missing. The counts make sure that no extra data items have been 
included. At each step of the proof the owner checks that the sizes of 
the next two subtrees along the path sum to the size of their parent. To 
make the whole process work, we also need to check that the size of the 
root (the sum of the counts of its two subtrees) matches N, the total 
size of the data set. We discuss these issues in more detail in the next 
section. 

2.4. Implementation Issues and Assumptions 

So far we have concentrated on the owner-publisher procedures and 
their proofs, but not the underlying communication mechanisms neces- 
sary to carry out the protocols. Theorem 1 shows that if all n owners 
follow the protocol correctly and approve their proofs for the digest value 
£ and for the correct data count value N. then users can be confident 
that the digest £ is for a BST which represents the combined data set. 
We now address the related issues of how to ensure that a User: 

1 knows all Owners approve the digest £ for the correct value of N. 

2 gets the digest £. 
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This will partly depend on what we assume the user knows about 
the n owners and what the owners know about each other. At one 
extreme we can assume a user knows the identity of all participating 
owners along with the owners' public keys, and thus could expect to see 
a signed approval from each owner. At the other extreme, a user may 
know none of the participating owners, but may relay on a trusted third 
party “moderator" to determine an appropriate set of owners to partic- 
ipate. In between, a user may know of some owners they want involved, 
but expect other owners to contribute as well. 

Using a Trusted Moderator, a trusted Moderator reduces the 
information both users and owners need about the set of owners. This 
is like an online Better Business organization which accepts owners who 
agree to follow the protocols. After an owner gets a correct proof for a 
digest value he sends a signed message to the Moderator: his approval, 
the digest, the size of his data set, the claimed total size of the entire 
data set. and the Publisher's web address. Once the Moderator gets an 
approval from all owners, it is easy to check that all owners approved 
the same digest and that the total of the individual sizes of the data sets 
matches the global data set size. The digest ^ for that Publisher can 
then be approved and posted (or, the Publisher gets a signed approval 
from the Moderator which can be given to users). 

With this scheme a user can get answers and have confidence that the 
digest they are using is correct without knowing anything in advance 
about the set of owners. They only need to know about (and trust) the 
Moderator, who can then provide a signed approval of the digest ^ to 
the Publisher who passes this on to the Users. Thus, the Moderator has 
much less overhead than the Publisher since he does not directly deal 
with the Owners' data sets (just a single acknowledgment per owner) 
and also need not deal directly with Users. 

Eliminating the Trusted Moderator using PKI, If we assume 
that users know which owners are involved and the owners' public keys, 
we can eliminate the need for a trusted Moderator, In this case, the 
publisher can give the user each owner’s signed accepl/reject response 
to The response would contain ^ and the count value each owner 
verified. The User would only need to know that the true count value was 
used to be confident that the Publisher’s computed digest is accurate. 
Any number of assumptions could be made that ensure that the correct 
data count value N is used, but a simple and reasonable assumption 
is that at Iea.st one Owner knows N. The User simply checks that all 
Owners agree on the count value. Even if no Owner initially knows N. 




Certifying Data from Multiple Sources 



57 



there are a number of efficient methods that a set of Owners could use 
to determine N. Any such method is sufficient to ensure the correctness 
of the Publisher computed digest value. 

2.5. Multi-dimensional Range Trees 

For a database containing a set of Nr- tuples, an r-dimension&l range 
query has the form answer is the set of points 

with all coordinates satisfying the corresponding range {(xi, . - . ,a^f) : 
< Utfor 1 < i < r}. These r-tuples can be efficiently found using 
a multidimensional range tree (MDRT) in time 0{log*’ N k) where fc 
is the number of r-tuples in the answer set [1]. This important setting 
allows us to support multi-attribute queries. In a 2D MDRT each data 
item d is stored in log N ordinary BSTs (all tied together in a larger 
data structure). Thus for each data item d an owner t gets a proof 
which has log N proofs similar to those used for a data item in the 
BST setting. The proof also has additional information tying the logN 
pieces together. Extending this result to higher dimensions, we get the 
following theorem: 

Theorem 2 For a set ofn owners with data sets D\ . .. Dn, where N 
is the number of data items in D » LCsiAj if each Owner correctly 
executes the MDRT certification protocol and accepts his proof for the 
digest of an r •dimensional range tree, then either 22 is the digest of an 
r- dimensional range tree over D or the Publisher has found a collision 
in the hash function H. 

The Publisher can compute the digest S and all proofs in 0{N \og^ N) 
time, and Owner i can verify’ his proof in 0(|Dt| log*^ N) time. 

3. Protocols for the Untrusted Owners Setting 

In this setting there may be “un trusted owners’* who may not follow 
the protocol. These owners may conspire with the publisher or other 
untrusted Owners to present false results. 

An owner does not see the publisher’s entire daUibitse, so cannot de- 
pend on the accuracy of data other than his own. However, an owner 
still wants assurance that any of his data that matches a query will be 
properly included in the answer, and that data not in his data set cannot 
be falsely attributed to him. We continue to assume that all data items 
have an identifier for the owner. Assuming no collisions in the hash func- 
tion are found, we show how to achieve the following guarantee for an 
honest owner when a user submits a single or multi -dimensional range 
query: if an owner O* accepts the publisher’s prxx>f for D{ and the user 
accepts the proof for the answer given to a query, then the data in the 
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answer attributed to 0* is exactly what 0^ should have returned if he had 
answered the query only on his data set Dj. Removing the assumption 
that all participating owners are trusted motivates our focus on individ- 
ual owners in the relaxed security statement,* We can also extend this 
result to multi-dimensional range queries in a fairly straightforward way. 
We state the one-dimensional result formally in theorem 3. 

Theorem 3 Letf{[<i,b],D) be a function which returns answers to one 
dimensional range queries on the collection of data sets D. If an owner 
Oj correctly executes the Owner BST certification protocol and accepts 
the proof of the digest S and the user correctly accepts the answer re- 
turned by the publisher, denoted arTs, then either 1) F([a, 6]»iPi) = 
ansODi or 2) the Publisher has found a collision in the hash function. 

3.1. Preventing Falsely Attributed Data 

We frequently want to prevent a dishonest publisher from giving the 
user data which is attributed to an honest owner, but is not in the 
owner’s data set. We can prevent such “false attribution" by adding an 
additional mechanism to our protocols. 

We describe a variation of our results in the untrusted setting where 
each data element is checked efficiently using a single hash computation. 
In the new approach, each data owner securely combines each data ele- 
ment with a secret value to form a means to authenticate the origin of 
that data element, the owner commits to the secret, and later the owner 
reveals the secret so that users can use the secret to authenticate the 
origin of the data elements. More specifically the protocol is as follows. 

1 Each owner, 0$ .generates a secret random number, 

2 Oj computes a message authentication code (MAC), for 

each data element d € A'. Tits MAC is the hash of each data 
element dosing a hash function keyed with the unrevealed random 
number 

3 O, passes each of his data elements and its corresponding message 
authentication code to the publisher. Also. 0» passes a commit- 



'in ihe presence of uiumsied owners, and thus unirusied daia, answers lo queries which 
depend on ihe enure data set are no longer reliable. For example, the minimum of the data 
values IS not useful since spurious data values could cause skewed results. 

'The size of kt should be chosen, with respect to the message authentication function la the 
next step, to be sufficiently large to prevent a variety of attacks on the system. 

^Note that we assume that k«y(d) makes It easy to determine the claimed owner of the data 
element, so the user can efficiently identify the k, of the owner. Otherwise, the user would 
have to check each of all possible owners to determine the owner 
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ment to fc* of the form so/t,, The publLsher now builds 

the Count Certified BST using as leaf values the pairs (d, (d)) 

which are still ordered by k€y(d). 

4 After receiving the inputs from all owners, the publisher commits 
to the root hash of the combined database, the list of data 
owners, and the commitments of each data owner, ^ 

= {E,Oi...O^.[saiti,/i*,(iai<i)]....,[saitj,/Uj(soi«;)]). 

5 Oi checks that the root hash properly reflects his data values essen- 
tially as in the prior section, and that is correct. 

He then reveals ki to the publisher along with his signed acceptance 
of Sptii. The publisher can now make the tuples available 

to the users in query responses along with signed acceptance 
of To verify the authenticity of a data element which appears 
to belong to 0», the user confirms that Oi signed and checks 
that fci corresponds to the Oj's secret commitment. Finally, the 
user verifies the message authentication ctxle on the data element 
using the corresponding fei. 

It takes 0(1) effort to check d € Di due to the hash commitment 
scheme and so for selection and range queries with T answers, verification 
now takes 0(1 ogA^ + 7) time and space for a ID range query and for 
r-dimensional range queries, verification takes 0(log’’ + T). 

4. Conclusion 

One main limitation of our scheme is the need for users to know 
who has approved the digest. This is likely to make updates harder 
and introduces extra overhead for the user and owners. In addition, we 
would like to extend our results to a wider class of query types, as was 
done for the single owner case in [12]. 
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Abstract In the datiba.se -as- a* service model, a service provider hosts the elicnis' 
data and allows accerfr to the data through the Inlcrncl Databasc*as> 
a* service model uffers considerable benefits (o organizations with data 
management needs by allowing them to outsource their data manage* 
menl inlraslruc lures. Yet. the model introduces many significant chaJ* 
lenges, in particular that of data privacy and security. Ensuring the 
integrity ol* the databa.se, which is hosted by a service provider, is a 
cridcaJ and challenging problem in this context We propose an en- 
crypted database integrity assurance scheme, which allows the owner 
of the data to ensure the integrity of the database hivvtcd at the ser- 
vice provider site, in addition to the security of the stored data against 
malicious attacks. 
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1. Introduction 

Rapid advances in networking and Internet technologies have fueled 
the emergence of the “softwarc-as-a- service" model, also referred as the 
Application Serviee Provider (ASP) model, for enterprise computing. 
Successful examples of commercially viable software services include 
re nt-a- spreadsheet, electronic mail services, general storage services, dis- 
aster protection services. Daiahast'-as-a-Service (DAS) model [11, 8, 9], 
inherits all the advantages of the ASP model by allowing organizations to 
leverage data management solutions provided by the service providers, 
without having to develop them on their own. It alleviates the need for 
organizations to purchase expeasive hardware and software, deal with 
software upgrades, and hire professionals for administrative and mainte- 
nance tasks. Instead, the new model allows third party database service 
providers the capability to seamlessly host data from diverse organi- 
zations and take over these tasks. By outsourcing, organizations can 
concentrate on their core competencies instead of sustaining a large in- 
vestment in data management infrastructures. Increasingly, large com- 
panies arc outsourcing their IT departments ajid sometimes their entire 
data centers to specialized service providers [6, 5]. 

NctDB2 system [11|, which is being developed at IBM in cooperation 
with University of California, Irvine, is an instantiation of DAS model. 
The system has been deployed on the Internet and under constant use 
for over two years. 

Among the others, data privacy ajid securiiy arc the most significant 
challenges in the DAS model. In the DAS model, the user data is stored 
at the service provider (ASP) site. The ASP stores the client’s data 
and the client poses queries against that database and the ASP (or the 
server) responds back to the client with results of the queries. Most 
companies ajid individuals view their data as an asset. The theft of 
intellectual properly already costs organizations great amount of money 
every year [4]. Therefore, first, the owner of the data needs to be assured 
that the data is protected against malicious attacks from outside of ASP. 
In addition to this, recent studies indicate that 40% of those attacks arc 
perpetrated by the insiders [4]. Hence, the second and more challenging 
problem is the privacy of the data when even the ASP itself is not trusted 
by the owner of the data. First problem is examined in [llj and the 
second one is studied in [8], which explores how SQL queries can be 
executed over encrypted data. 
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In this paper, we look ai another important issue that arises in the 
conlcxl of the sceond problem staled above. Although the elient's data 
is protected against holh outsiders and the ASP with data eneryplion 
techniques, how can the client ensure the integrity of the database, which 
belongs lo the client but is under the control of the ASP? Our prelim- 
inary work on this issue appears in [10|. That work docs not provide 
efficient schemes to ensure the table-level integrity. Here we present 
efficienl incremental techniques lo ensure the table-level integrity and 
discuss the applicability of the schemes in real database environments. 
The previous work also fails to assess the performance implicalions of 
ihe integrity assurance schemes. In this paper, we experimentally eval- 
uated the performance of the schemes we propose by using the standard 
benchmark queries. 

We view the integrity problem in two dimensions. First, when the 
clienl receives a record from Ihe sever, how can the client ensure Ihe 
integrity of the record ? Thai is, how can the clienl verify that the 
data has not been changed in an unauthorized way ? Second, the client 
needs to assure the integrity of whole table stored at Ihe server site. 
This problem is more pronounced in dynamic environments, where the 
update rale of the database is high. In such environments, the clienl 
needs efficienl mechanisms, which will require minimal computational 
resources that are limited at the clienl site. While entailing minimal 
compulational resources, preferred solution is a mechanism that can be 
automated requiring minimum human involvement. In this paper, we 
present such a solution lo ensure Ihe inlegrily of hosted databases. 

Integrity problems may arise both from malicious or non-malicious 
circumslances. Malicious threats may originate from misbehaving server 
or some other adversary who breaks into the system. Active and replay 
(restore) attacks, as described in [12], are the typical examples for those 
kinds of threats. Non-malieious threats can also have many sources. 
One example for those is system failures. ASP may experience a system 
breakdown and may not be able to recover all user data from on-line 
and/or archive sources. In those cases, the clienl does nol have any 
verification mechanism lo delecl the integrity of the original data. In 
the course of NctDB2 project, we have particularly observed the need for 
addressing data inlegrity problems raised from second group of sources, 
namely; non-malicious threats. 

To address these issues, we propose Iwo-lcvcl encrypted databa.se in- 
tegrity scheme, which consists of Record-Level integrity and Table-Level 
/nregriA' concepts. Those arc developed in Ihe context of Ihe DAS model 
and described in Section 3.2 and Secdon 3.3, respectively. We note that, 
ihc techniques we present in this paper are not specific lo either Ihc DAS 
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Figure L Databa.se*a&*a'S«rvice archiieciure 



model or the encrypted databases but have wider applicability to any 
relational data that is subject to integrity issues. Once implementation 
of these techniques is in place, the system can automatically detect the 
integrity violations and intrusions. 

The rest of the paper is organized as follows. Section 2 provides back- 
ground on the DAS model and the encrypted database storage model. 
Secdon 3 presents our solution to encrypted database integrity by dis- 
cussing the record-level and the table-level integrity techniques. Sec- 
tion 4 gives our experimental results on queries from the TPC-H bench- 
mark, We conclude the paper in Section 5. 

2. Background 

2.1. Database-as-a-Service Model 

The system we use in this study is based on the architecture proposed 
and described in [8] and [9]. The basic architecture and the control flow 
of the system are shown in Figure 1, It is comprised of three fundamen- 
tal entities. A u^er poses the query to the client. A server is hosted 
by the service provider that stores the encrypted database. The en- 
crypted database is augmented with additional information (which we 
call the index) that allows certain amount of query processing to oc- 
cur at the server without jeopardizing data privacy. A clieni stores the 
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data at Ihc server. Client' also maintains metadata for translating user 
queries to the appropriate representation on the server, and performs 
post“proeessing on server query results. From the privacy perspeetive, 
the most important feature is. the client’s data is always stored in en- 
erypted form at the server site. The server never sees the unenerypled 
form of the data, and executes the queries directly over encrypted data 
without decrypting it. We fully studied the query processing techniques, 
which allow this process, in [8). 

2.2. Encrypted Database Storage Model 

We briefly summarize how the client’s data stored at the server in an 
encrypted fashion.' Following this we introduce oiu* extensions to the 
model to implement data integrity techniques. 

For each relation . . ,v4n), 'A'c store, on the server, an en- 
crypted relation: y^i > • ■ • ^PJ)^ where 

Here, an e tuple stores an encrypted string 
that corresponds to a tuple in relation R. Each attribute stores 
the partition index for conesponding attribute A{ that will be used for 



* Often the client and (he iiiier might he (he .same entity. 

^We will net repeat here all of the details of storage model, since they are thoroughly discussed 
in 1^]. Rather, we only provide rtecessary notations to explain the constructs we develop in 
this work. 
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query processing al the server. represents the encrypted form of the 
attribute value of conesponding attribute Aj. 

For example, consider a relation emp given in Table 1 that stores 
the information about the employees. The emp table is mapped to 
a corresponding table, shown in Table 2, at the server: emp^{RIDy 
e tuple, ename**^, salary^^, eid^, ename^) 

RID represents record identifier, which we will use in Section 3.3. 
The second column etuple contains the string corresponding to the en- 
crypted tuples in emp. For instance, the first tuple is encrypted to 

” that is equal to ^:*(1,23, Tom, lOK. Maple, 40), 
where ^ is a deterministic encryption algorithm with key k. Any deter- 
ministic encryption technique such as AES [1], Blowfish [14], DES [7] 
etc., can be used to encrypt the tuples. The third column corresponds 
to the index on the employee ids,' The sixth column represents the 
individually encrypted values employee ids. 

3. Encrypted Database Integrity 

We study the integrity of a database at two different granularity levels, 
1) Integrity of the records, 2) Integrity of a table. We call the former as 
Record-Level Integrity and the latter as Table-Level Integrity. 

3.1. Preliminaries 

In this subsection we provide necessary definitions and concepts that 
we use in the rest of the section. Our definitions are ba.sed on [12, 15]. 

• A ha.’ih function is a function h, which has, as a minimum, the 
following properties: 1) Compre.^.^ion, meaning h maps an input xof 
arbitrary finite bitlength to an output h(x) of fixed bitlength n and 2) 
Ea.’te of computation, meaning given h and an input x, k{x) i^> ^">y to 
compute. 

• A one-way function is a function / that for each x from the domain of 

it is ea.sy to compute f{x), but it is computationally infeasible to find 

any x such that y — f{x). A hashfunction k(x) is collision resiaiant iHx 
is computationally infeasible to find any two distinct inputs x,x‘ where 
* hisf). 

• The manipulation detection codes (MDC.s) are one-way collision re- 
sistant hash functions that provide a representative image or ha.sh of a 
message. 



Deiaih ofcreaiion of those index valuer can be found in 
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Figure 2. Record-level imcgrily with RiCs 



♦ The dafa iniegriiy, in general, can be defined as a property, which 
guarantees that the data has not been manipulated in an unauthorized 
manner since the time it was created by an authorized spuree. MDCs 
provide this level data integrity in combination with data encryption. 

As we will sec, we need to expand this definition to satisfy data in- 
tegrity requirements in the DAS model. This definition only provides 
data integrity for individual records stored in the database at the server 
site. In addition to that, we want to ensure the integrity of tables in an 
efficient way, 

3.2. Record-Level Integrity 

The record-level integrity represents that the content of a record has 
not been manipulated in an unauthorized manner. Although it may 
not be apparent, data encryption does not provide data integrity auto- 
matically. The owner of the decryption key can decrypt the encrypted 
messages, which were encrypted with the same key. But this docs not 
guarantee that the encrypted message has not been manipulated by the 
adversary. The discussion of how encrypted messages can be manipu- 
lated undetectably can be found in [12). This motivates the need for 
data integrity measures over encrypted data. 

To provide record-level integrity we propase a scheme based on Record 
Iniegriry Codes (RlCs). RJCs are specially computed representative im- 
ages for each record with certain security and uniqueness measures. Fig- 
ure 2 shows the procedure that provides record-level data integrity. The 
client has a record r that will be inserted into the database, which is 
maintained by the application service provider or simply the server. The 
client first computes the hash code of the record H = h{r) by using a 
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hashing algorithm, which produces Record Iniegriiy Code (RIC). This 
can be any algorithm, which satisfies the security requirements given 
before. Here we use MDCs for this purpose. After this step, the client 
coneatenates the hash code H with the original record text r and en- 
crypts them together by using any deterministic encryption algorithm S 
with secret key jfc, i.e., the client computes ciphertext C “ || h{r)), 

where || represents concatenation. The client inserts ciphertext C as an 
eiuple into the database. 

Whenever the client requests a record, the server sends back the corre- 
sponding eiuple in encrypted form. To verify the integrity of the record, 
the client first decrypts the recovering t' snd which is the RIC. 
parts. Since only the client has the secret key k for encryption algorithm 
no one else can decrypt. Then the client independently computes h(r') 
of received record r* and compares that with the hash code //'. If they 
are equivalent, this verifies that the received record is authentic and 
has data integrity, i,e., has not been manipulated in an unauthorized 
manner, 

3.3. Table-Level Integrity 

In the previous section we discussed mechanisms that enable the client 
to test the integrity of individual the records returned by the server. In 
this section, we study schemes, which allow the client to validate the 
integrity of the tablc(s). 

The integrity of a tabic may be compromised by an adversary by mod- 
ifying. adding, or deleting some or all of the records. An unauthorized 
modification on records can be detected by the record-level integrity 
techniques, when they arc queried by the client. However, the record- 
level integrity is not enough to detect unauthorized addition and/or 
deletion of records in any ca.se. 

To successfully detect such modifications, we propose a mechanism, 
which creates a signature for each table. Those signatures can be thought 
of the fingerprints of the corresponding tables. They are created, up- 
dated, and stored at the client site in a secure way. Hence, an adversary 
cannot re-compute the signature and verification of the signature the 
would detect the unauthorized modifications. Considering our focus on 
security, the signatures should be resilient against various cryptographic 
attacks. 

In addition to that, we make note of another important issue regarding 
the computation of the signatures. The client should re-compute the 
signature when he inscrts/deletcs a record from a table. This is an extra 
overhead for the client and can be significant in terms of system resources 
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al ihc client sice and network traffic. Undoubtedly, a highly preferred 
alternative would be a scheme, which allows incremental updates on 
the signatures instead of requiring the processing of all of the existent 
records. 



3.3.1 Incremental Signatures. To achieve the incremental up- 
dates on signatures, we make use of specialized schemes, XOR MACs, 
introduced by Bell are et aJ. [3. 2|, in the context of incremental cryptog- 
raphy [2]. The main idea is; when there is a change in a document D. to 
construct mechanisms to reflect “only the changes” on the cryptographic 
transformation (in our case the signatures) of the document D without 
processing all the document from scratch. Hence, such an incremental 
algorithms run time would be proportional to the number of changes 
but not proportional to the document length. Forinal definition of XOR 
scheme we use in this study is given in [3] as follows: 

f\ is a pseudorandom function (PRF) with secret key k\ and /g ^ 
pseudorandom permutation (PRP) with secret key kz- called 

randomizer, is an algorithm, which given a string x picks a random A:-bit 
string r and returns a; |{ r. The message that will be authenticated is 
D=s Oq[\ Di II . . . II II Dn+i. where Dp is a special start symbol and 
Dn+i is a special end symbol. Then the tag of the message is computed 
in three steps: 

1 Randomize: Lci = Rand{Di ) : 0 < i < n 

2 Chain: Let k * 

3 Tag: Let T = / 2 (h) 

In our system setup, Oi & are defined as the database records of the 
table and the tag T corresponds to the signature S of the table. (3J 
discusses possible instantiation alternatives for PRF /j, such as using 
DBS. MD5, or both. The instantiation of /j can be handled in a similar 
way as a block-cipher can be viewed as a PRP. For simplicity, we assume 
that size of a database record is equal to block size of the block-cipher. 
If record size is larger, then it can be processed as multiple blocks. If it 
is smaller than the block size, the standard padding techniques can be 
used. Security of the scheme also analyzed thoroughly in [3] against the 
various types of attacks. 

Insert: We use the record identifiers (RIDs) to keep track of the in- 
dex of the records ri in the algorithm. Note that, although the RIDs are 
stored in the clear at the server, they arc also included in the e tuples 
in the encrypted form, (Sec Section 2.2) Therefore, even the server 
manipulates the RIDs. the client can always recover the original ones 
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by decrypting the efuples. We assume that the RIDs arc always non- 
decreasing unique numbers. (Most of commercial database systems al- 
ready provide table definitions to create this type of ids.) 

Assume that the current signature of a table is S and the RID of the 
last record is i. If the client inserts a new record (i,e,, RID=i + 1), 
then the new signature S' is computed as follows: 

1 The client recovers hash value as h = 

2 The client moves the special end record one position forward by 
assigning — -ft+i (Note that here ft+i is not the randomized 
form of the new record being inserted but the randomized form of 
the special end record,) 

3 The client computes Rj+i * Rand(r|-|.i) 

4 The client updates the hash value by: 

5 The client computes the new signature T* * /iih') 

Delete: Deletions are reflected on the signature in an incremental way 
as follows. Assume that the current signature of a table is S and the 
client wants to delete a record r, (i,e.. RID=0i then the new signature 
S' is computed as follows: 

1 The client recovers hash value h os h ^ /’*(5) 

2 The client updates h by: 

3 The client computes the new signature 7^ = 

Incrementing requires five calls to the PRF. This is a significant sav- 
ing as compare to computing the signature from scratch, which would 
require one call for each record in the table. 

3.3.2 Application of the Incremental Signatures. We have 
presented the incremental signature computation formally. The scheme 
uses the RIDs as record indexes, which are also employed in the com- 
putation steps. Now. we will discuss the realization of the scheme in 
database applications. 

The insertion operation does not pose any difficulty. Since the RIDs 
are always incrementing unique numbers, the client inserts a new record 
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with a new RID and updates the signature of the table. On the other 
hand, deletion operation requires some more work. 

In typicaJ database applications, the users usually don’t query the 
records with their RIDs. As an example, if we want to delete a record 
of an employee whose employee id is 123 from employee table, a typical 
query would be: 

DELETE PROH employee UHEKB eld - 12$ 

To execute this deletion, the client runs two queries to obtain the 
RIDs and the e tuples required to compute the updated signature. 

The first query retrieves the RID of the record being deleted as follows: 

SELECT rid.etuple FROM employee WHERE eid^ « £(123) 

Let us assume that the RID of the corresponding record is 345, then 
the second query retrieves the RIDs of two records, whose RJDs are 
the immediate predecesst)r and successor of the RID of the record being 
deleted."* 

(SELECTT rid tuple FROM employee 

WHERE rid < 345 ORDER BY rid DESC FETCH FIRST ROW ONLY) 
UNION 

(SELECT rid.etuple FROM employee 

WHERE rid > $45 ORDER BY rid ASC FETCH FIRST ROW ONLY) 

After running this query, the client would have enough information 
to update the signature of the table. 

We used equality predicate in the WHERE clause of the query for this 
example. We note that, if the query has inequality predicates then the 
approach should be different. In that case, the client could use partition 
indexes (See Secdon 2.2) instead of the field-level encrypted values to 
obtain the necessary information.^ What the client needs are RIDs and 
conesponding etuples in any case. Therefore, the queries should be re- 
formulated accordingly to retrieve that information by utilizing partition 
indexes. 

We also note that SQL update operations cim be implemented as the 
combination of delete and insert. 



^SQL queries given below liave been executed on IBM DB2 vS.l. 
Query proce.uing with parti lion indexes i.t fully discussed in [Sj. 
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Figure S. Client response lime 



Figure 6. Total query response lime 



4. Experimental Evaluation 

Wc have conducted experiments to evaluate the overhead introduced 
by the record-level integrity schemes chat wc have presented. Our re- 
sults showed that the overheads arc not significant. We used the stan- 
dard TPC-H benchmark [16] queries, specifically Q#3. Q#6, Q#12 from 
TPC-H suite. The TPC-H dacj^ase was created in scale factor 1. which 
corresponds to 1GB in size. To implement the integrity schemes, we 
used the AES block cipher |1] as the encryption algorithm, and the MD5 
message digest [13] as the one-way hash function. The experiments were 
executed on a server, which had a Pentium lIl-750MHz CPU, 256MB 
RAM, Windows TOCO OS. and IBM DB2 UDB v8.1. 

To provide the detailed analysis, wc report the results for the server 
side queries, the client side queries, and the total query elapsed times. 
In ail figures, wc compare two cases, namely; the case, where there is 
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no integrity scheme is deployed and the case, where the record-level 
integrity schemes we have presented arc implemented. 

Figure 3 shows the overhead in server side query response times. On 
the average the increase is \1%. Figure 4 presents the increase in the 
number of l/Os executed at the server site. The increase, \2% on the 
average, is mainly due to the increase in the tuple sizes. The tuple sizes 
increase as a result of inclusion of the RICs into the records and it is 
reflected to server side query response time. 

Figure 5 shows the measurements for client side query CPU time. It 
increased, constantly for all queries, by 70%. The overhead is due to 
the increased number of bytes that are decrypted and the validation of 
the integrity of the tuples by the client. The total query response time, 
which is presented in Figure 6. showed 18% increase on the average, 
which did not constitute significant overhead. 

5. Conclusions 

We have studied the crucial problem of encrypted database integrity 
in the context of database-as-a-service model. We have proposed two- 
level encrypted database integrity scheme, which consists oi Record-Level 
Integrity and Table-Level Integrity concepts, as a solution to this prob- 
lem, Our scheme is combined with encrypted database storage model. 
Consequently, the resultant system provides the security of the stored 
data against the malicious attacks as well as the database integrity fea- 
tures, which ensure the authenticity and the validity of the data stored 
at the service provider site. 
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Abstract Imrusiion alert correlation is the process to identify high-level attack acenariof; 

by reasoning about low-level alens raised by intrusion detection systems (IDSs). 
The efficiency of intrusion alert corrclalion is critical in enabling interactive 
analysis of intrusion alens as well as prompt responses to attacks. This paper 
presents an experinvenial study aimed at adapting main nvemory index struc- 
tures (e,g., T Trees. Lirtear Hashing) arui database query optimization techniques 
(e,g, nested loop join, sortjoin) for efficient correlation of intensive alerts. By 
taking advantage of the characteristics of the alert correlation process, this pa- 
per presents three techniques rmned hyper-aterf container, two-tevel index, and 
sort correlation. This paper then reports a scries of experiments designed to 
evaluate the effectiveness of these techniques. These experiments demonstrate 
that ( 1 ) hyper-alert containers improve the efficiency of order-preserving index 
.structures (e.g., T Trees), with which an insertion operation involves search, (2) 
two-level index improvc.s the efficiency of all index structures, (2) a two-level 
index structure combining Chained Bucket Ha.shing and Linear Hashing is the 
most efficient for streamed alerts with and without memory constraint, and (4) 
sort correlation with heap .sort algorithm is the most efficient for alert correlation 
in batch. 

Keywords: Intrusion detection, i ntrusion alert correlation, query optimization 

1. Introduction 

TradiiionaJ inirusion detection systems (IDSs) focus on low-level attacks or 
anomalies, and raise alens independently, though there may be logical connec- 
tions between them. In situations where there are intensive intrusions, not only 
will actual alerts be mixed with false alens. but the amount of alerts will also 



work i« paiUally suppoited by ihe NaiioruU Science Foundation under grants CCR-0207297 and ITR- 
(12193 IS. by the U.S. Army Re.«arcK Office under gram DA AD 1^-1-0219. The auihor.ti would like to 
thank the anonymous reviewers for iheir valuable suggestions. 





76 



DATA AND APPUCAT!ONS SECURnYXVH 



become unmanageable. As a result, ii is difficult for human users or intrusion 
response systems to understand the aJens and take appropriate actions. 

To assist the analysis of intrusion aJens. several alert correlation methods 
(e,g., (6, 15J) have been proposed recently to process the alerts reported by 
IDSs. As one of the methods, we have developed an alert correlation tech- 
nique using prerequisites and consequences of attacks (11], Intuitively, the 
prerequisite of an intrusion is the necessary condition for the intrusion to be 
successful, while the consequence of an intrusion is the possible outcome of 
the intrusion. Based on the prerequisites and consequences of different types of 
attacks, our method correlates alerts by (partially) matching the consequence 
of some previous alerts and the prerequisite of some later ones. 

We have implemented an offline intrusion alert correlator based on our ap- 
proach, and the initial expen ments indicate that our approach is promising 
in constructing attack scenarios and differentiating true and false alerts (llj. 
However, our solution still faces some challenges. In particular, we imple- 
mented the previous intrusion alert correlator as a DBMS -based application 
(11], Involving a DBMS in the alert correlation process provided enormous 
convenience and support in intrusion analysis; however, relying entirely on the 
DBMS also introduced performance penalty. For example, to correlate about 
65,()()0 alerts generated from the DEFCON 8 CTF data set, it took the alert 
correlator more than 4 minutes. Such performance is clearly insufficient to 
be practical, especially for interactive analysis of intensive alerts. Our timing 
analysis indicates that the performance bottleneck lies in the interaction be- 
tween the intrusion alert correlator and the DBMS, Since this implementation 
completely relies on the DBMS, processing of each single alert entails interac- 
tion with the DBMS, which introduces significant performance penalty. 

In this paper, we address this problem by performing alert correlation en- 
tirely in main memory, while only using the DBMS as the storage of intrusion 
alerts. We study several main memory index structures, including Array Binary 
Search [2], AVL Trees [I], B Trees [3], Chained Bucket Hashing [8]. Linear 
Hashing [10], and T Trees (9J, as well as some database query optimization 
techniques such as nested loop join and sort join [7] to facilitate timely corre- 
lation of intrusion alerts. By taking advantage of the characteristics of the alert 
correlation process, we develop three techniques named hyper-alert coniatner, 
two-level index, and sort correlation, which further reduce the execution time 
required by alert correlation. 

We performed a series of experiments to evaluate these techniques with 
the DEF CON 8 CTF data set. The experimental results demonstrate that (I) 
hyper-alert containers improve the efficiency of index structures with which an 
insertion operation involves search (e.g.. B Trees, T Trees). (2) two-level index 
improves the efficiency of all index structures, (3) a two-level index structure 
combining Chained Bucket Hashing and Linear Hashing is most efficient for 
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coTTelating itreiimed aJerls with aiuJ without memory constraint, and (4) sort 
correlation with heap sort algorithm is most efficient for alert correlation in 
batch. With the most efficient method, the execution time for correlating the 
aJerls generated from the DEF CON 8 CTF data set is reduc*ed from over four 
minutes to less than one second. 

The remainder of this paper is organized as follows. To be self contained, the 
next section briefly describes our alert correladon method. Section 3 presents 
our adaptations of the main memory index structures and some join methods. 
Section 4 reports our implementation and experimental results. Section 5 dis- 
cusses the related work, and Section 6 concludes this paper and points out 
some future research directions, 

2. An Overview of Alert Correlation 

This section briefly descTibes our model for correlating alerts using prereq- 
uisites and consequences of intrusions. Further details can be found in (11). 

The alert correlation model is based on the observation that in series of 
attacks, the component attacks are usually not isolated, but related as differ- 
ent stages of the attacks, with the early ones preparing for the later ones. To 
take advantage of this observation, we correlate alerts using prerequisites and 
consequences of the corresponding attacks. Intuitively, the prerequisite of an 
attack is the necessary condition for the attack to be successful, while the con- 
sequence of an attack is the possible outcome of the attack if it is successful. 
We identify the prerequisites (e.g., existence of vulnerable servic*es) and the 
consequences (e.g,, discovery of vulnerable services) of each type of attacks 
and cx>rrelate detected attacks (i,e., alerts) by matching the consequenc*es of 
previous alerts and the prerequisites of later ones. 

We use predicates as basic constructs to represent prerequisites and conse- 
quences of attacks. For example, we may use the predicate UDPVulnerahle- 
ToBOF(VictimIP, VictimPort}to represent the discovery of a vulnerable UDP 
service. We use a h\per-alert type to encxxle our knowledge about each type of 
attacks, A hvper-alert type T is a triple (fact, prerequisite, consequence ) where 

( 1) /flcr is a set of attribute names, each with an associated domain of values, 

(2) prerequisite is a logical formula whose free variables are all mfact, and (3) 
consequence is a set of logical formulas such that all the free variables in con- 
sequence are in fact. Intuitively, the/ocr component of a hyper-alert type gives 
the information associated with the prerequisite specifies what must be 
true for the attack to be successful, and consequence describes what could be 
true if the attack indeed happens. For brevity, we omit the domains associated 
with attribute names when they are clear from context. 

Given ahyper-alerl type 7*= {fact, prerequisite, consequence), a hyper-alert 
t instance) h of type Tis a finite set of tuples on fact, where each tuple is ass<x:i- 
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aled wilh an interval-based lbegin_iime, endjimej. The hyper-aJcrt 

h implies Xh^i prerequisite must evaluate to True and all the logical formulas 
in consequence might evaluate to True for each tuple. The fact component of a 
hyper-alert type is essentially a relation schema (as in relational databases), and 
a hyper-alert is a relation instance of this schema. A hyper-alert insianitaies 
its prerequisite and consequence by replacing the free variables in prerequisite 
and consequence with its specific values. Note that prerequisite and conse- 
quence can be instantiated multiple times if /flcr consists of multiple tuples. 

To correlate hyper-alerts, we check if an earlier hyper-alert contributes to 
the prerequisite of a later one. Specifically, we decompose the prerequisite of 
a hyper-alert into parts of predicates and test whether the consequence of an 
earlier hyper-alert makes some parts of the prerequisite True {i.e.. makes the 
prerequisite easier to satisfy). If the result is positive, then we correlate the 
hyper-alerts. In our formal model, given an instance A of the hyper-alert type 
T= if act, prerequisite, consequence), the prerequisite set (or consequence set, 
resp.) ofh, denoted (orC'(ft),resp«). is the set of all such predicates that 
appear in prerequisite (or consequence, resp.) whose arguments are replaced 
with the corresponding attribute values of each tuple in ft. Each element in 
P{h) (orC(ft), resp.) is associated with the timestamp of the corresponding 
tuple in ft. We say that hyper-alert ftj prepares for hyper-alert h2 if there 
exist p € P(fta)and C C C{hi) such that for all c € C, c.end_time< 
p.beginjime and the conjunction of all the logical formulas in C implies p. 

We use a hyper-alert correlation graph to represent a set of correlated hyper- 
alerts. Specifically, a kyper-alert correlation graph CG = (N. E) is a con- 
nected graph, where N is a set of hyper-alerts and for each pair nj, nj € N, 
there is a directed edge from m to rt 2 in E if and only if fij prepares forn 2 . 
Figure I shows one of the hyper-alert correlation graphs discovered in our ex- 
periments with the 2000 DARPA intrusion detection evaluation data sets [ 1 1 ] . 
Each node in Figure 1 represents a hyper-alert. The numbers inside the nodes 
are the alert ID's generated by the IDSs, 
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Figure I . A hyper-aJert correlaiion graph 



We have implemented an intrusion alert coirelator using our method [ll], 
which is a Java application that interacts with the DBMS via JDBC. In this 
implementation, we expand the consequence set of each hyper-alert by includ- 
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ing all the predicales implied by the wnsequence set. We call the result the 
expanded consequence set of the hyper-alert. The predicates in bc^th prerequi- 
site and expanded wnsequence sets of the hyper-alerts are then encxxled into 
strings called Encoded Predicate and stored in two tables. PrereqSel and Ex- 
pondedConseqSet. along with the corresponding hyper-alert ID and timestamp. 
Both tables have attributes HyperAlerllD, EncodedPredicate, beginjime, and 
end_time, with meanings as indicated by their ixames. As a result, alert corre- 
lation can be performed using the following SQL statement: 

SELECT DISTINCT c.Hypet AIcrtlD, p.HyperAlertlD 

PROM PrereqSet p. Exp&ndetlConseqSet c 

WHERE p.EncodedPr^icftte s c.EncodedPredicete AND c.endJinie < p.beginJime 

As discussed earlier, one problem of the intrusion alert cx^rrelator is its effi- 
ciency because of its dependence on, and intensive interacdon with the DBMS. 
In this paper, we address this problem by performing alert correlation entirely 
in main memory, while only using the DBMS as the storage of intrusion alerts. 
In the following, we study how to improve performance of alert cx^nelation 
by adapting database query opdmization techniques, including various main 
memory index structures. 

3. Adapting Query Optimization Techniques 

The essential problem in this work is how to perform the SQL query in the 
previous section efficiently. One opdon is to use database query optimization 
techniques, which have been studied extensively for both disk based and main 
memory databases. However, alert cx^rrelation has a different access pattern 
than typical database applicadons, which may lead to different performance 
than traditional database applications. In addidon, the unique characterisdcs in 
alert cx^rreladon give us an opportunity for further improvement. Thus, in this 
section, we seek ways to improve alert cx^rreladon by adapting exisdng query 
optimizadon techniques. 

In our study, we study the suitability of the following main memory in- 
dex structures: Array Binary Search [2]. A VL Trees [1]. B Trees [3), Chained 
Bucket Hashing (8]. Linear Hashing [10), and T Trees [9]. We do not de- 
scribe them here, sir>ce the related information can be found in the referenc'es. 
For comparison purpose, we also implement a naive, sequential scan meduxl, 
which simply scans in an (unordered) array for the desired data item. 

3.1. Correlating Streamed Intrusion Alerts 

We first study alert correlation methods that deal with intrusion alert streams 
continuously generated by IDSs, With such methods, an alert cx^rrelation sys- 
tem can be pipelined with IDSs and produce correlation result in a timely man- 
ner. 
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Figure 2 presents a nested loop method that can accommodate streamed 
aJerts. (As the name suggests, nested loop correlation is adapted from nested 
loopjoin [7],) It assumes that the input hyper-alerts are ordered ascendingly in 
terms of their beginning time. The nested loop method takes advantage of main 
memory index structures such as Linear Hashing, While processing the hyper- 
alerts, it maintains an index structure X for the instantiated predicates in the 
expanded consequence sets along with the corresponding hyper-aJerts. Each 
time when a hyper-alert h is processed, the algorithm searches in X for each 
instantiated predicate p that appears in ft ’ s prerequisite set. A match of a hyper- 
alert ft' implies that ft' has the same instantiated predicate p in ics expanded 
consequent set. It ft'.EndTime is before ft.BeginTime, then ft' prepares for 
ft. If the method processes all the hyper-alens in the ascending order of their 
beginning time, it is easy to see that the nested loop method can find all and 
only the prepare-for relations between the input hyper-alerts. 

Owllinc of Nested Loop Conation 

Input: A Use H of hyper-alens ordered eseendingly In their beginning Hines. 

Output: All pajcs oF (h', h) such that both h and h' are in H and k' prepares for h. 

Method: 

Maintain an index sUveture X fer inslantialed predicates in the expanded con^uence 

sets of hyper-alerts. Each insianiiated predicate Is associated with the corresponding 

hyper-alert. Initially, J is empty. 

1 . fbr each hyper-alen A in (accessed in ihe given order) 

2. for each instantiated predicate p m Ihe pcerequixite set of A 

3. Search (he sei of hyper-alens with index key p in Z. Let fP be the result. 

4. for each h' in H' 

5. If (A'.EodTime< h BeginTime) then oulput (A^ A). 

6. for each p in ihe emended consequeoce sei of A 

7. Insert p along with A iolo Z. 

end 

Figure 2. Outline of (he nested loop alen correiaicon methods 

The nested loop correlation method ha.s differeni performance if different in- 
dex siruciures are used. Thus, one of our ia.sks is to identify the index struciure 
most suitable for ihis method. In addition, we further develop two adaptations 
10 improve the performance of these index structures. Our firsi adaptation is 
based on the following observation. 

Observation 1 Multiple hyper-alerts may share the same insianiiated predi- 
cate in their expanded consequence sets. Almost all of them prepare for a later 
hxper-alert that has the same instantiated predicate in its prerequisite set. 

Observation 1 implies thai we can associate hyper-alerts with an insianti- 
ated predicate p if p appears in the expanded consequence sets of all these 
hyper-alens. As a result, locating an instantiated predicate directly leads lo 
the locations of all ihe hyper-alerts that share the instantiated predicate in iheir 
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expajuied consequence sets. We call Ihe set of hyper-aJeits asMx;iated with an 
insLintiaied predicate a hyper-alert container. 

Using hyper-alert containers does not always result in better performance. 
There are two types of accesses to the index structure in the nested loop cor- 
relation method: insertion and search. For the index structures that preserve 
the order of data items, insertion implies search, since each time when an ele- 
ment is inserted into the index structure, it has to be placed in the “right" place. 
Using hyper-alert container tkws not increase the insertion cost significantly, 
while at the same time reduces the search cost However, for the non-order 
preserving index structures such as Linear Hashing, insertion does not involve 
search. Using hyper-alert containers would force to perform a search, since 
the hyper-alerts have to be put into the right container. In this case, hyper-alert 
container decreases the search cost but increases the insertion cost, and it is not 
straightforward to determine whether the overall cost is decTeased or not. We 
study this through experiments later. 

Observalion 2 There is a small, static, and finite set of predicates. Two in- 
stantiated predicates are the same only if they are instantiated from the same 
predicate. 

Observation 2 leads to a two-level index structure. Each instantiated pred- 
icate can be split into two parts, the .predicate name and the arguments. The 
top-level index is built on the predicate names. Since we usually have a static 
and small set of predicate names, we use Chained Bucket Hashing for this 
purpose. Each element in the tt^-level index further points to a second-level 
index structure. The second-level index is built on the arguments of the instan- 
tiated predicates. When an instandated predicate is inserted into a two-level 
index structure, we first locate the right hash bucket based on the predicate 
name, then locate the second-level index structure within the hash bucket (by 
scanning the bucket elements), and finally insert it into the second-level index 
structure using the arguments. 

3.2. Correlating Intrusion Alerts in Batch 

Some applications allow alerts to be prtx:essed in batch (e,g.. forensic anal- 
ysis with an alert databa.se). Though the nested l(x>p method discussed earlier 
is still applicable, there are more efficient ways for alert correlation in batch. 

Figure 3 presents a sort correlation method, which is adapted from sort join 
[7j, The sort coireladon meduxl achieves good performance by taking advan- 
tage of efficient main memory sorting algorithms. Specifically, it uses two ar- 
rays. ApfQ and Apre stores the instantiated predicates in the prerequisite 

sets of the hyper-alerts {along with the corresponding hyper-alerts), and Aeon 
stores the instantiated predicates in the expanded consequence sets (along with 
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Oullioe of Sort CorrelAlion 
In pul: A set N of hyper-alens. 

Output: All pairs of h) &jch that both h and h' are in H and h' prepares for h. 
Method: 

Prepare (wo arrays Apr« and each emry of which is a hyper-aJeit associated with 
a field. Each airay is initialized with a reasonable size, and reallocated with doubled 
sizes if out of space. Existing conteoi is copied to the new buffer if reallocation happens. 

1. for each A ui H 

2. for each p in the prerequisite set of h 

3. Append h to Ap,,. with key = p. 

4. for each p in the expanded coosequence set of h 

5. Append h to A eon with key = p. 

6. Sort Apre &od Aetm ascendingly in terms of the Jeep field ( with, e.g. , heap sort). 

7. Partition the entries in Apre and Aeon into maximal blocks that share the same 
instantiated predicate. Assume Apn and Aeon have Bpre and Bran blocks, re^ 

8. t = 0, j = 0. 

9. while (< < Ifpre and j < Bc«n) do 

10. if <Apro.B,.Predtc<ifc < Aocn.B,.Predicate)tben 

11. i = i + l. 

12. else if (Apre* ^t.Predscoie > Acon-Bj.Predicuie) then 

13. > = i + l. 

14. else for c&ch h in Apr«.Bi and each h' iaAe^ Dj 

15. if h'.BndTime < A.BcpsnT'ime then output (/i\ h). 

16. I = t + I J * j + 1. 
end 



Figure S. The .sort correlation method 

the corresponding hyper*alerts). This method then sons both anays in terms of 
(he insiatuiaied predicate wiih an efficient sorting algorithm (e.g„ heap son). 

Assume both arrays are sorted ascendmgly in terms of instantiated predi- 
cate. The sort correlation method partitions boih arrays inio blocks that share 
the same instantiated predicate, and scans both arrays simultaneously. It main- 
tains two indices, i and that references to the curreni blocks in Apre 
Aeon- respectively. The method compares the instantiated predicates in the 
two current blocks. If the instantiated predicate in the current block of Apre 
is smaller, it advances the index i; if the instantiated predicate in the current 
block is smaller, it advances the index j; otherwise, the current blocks of 
Apre^nd Aeon share the same instantiated predicate. The method then exam- 
ines each pair of hyper-alerts A' and A, where A' and A are in the current block 
of Aeon and Apre. respectively. If the end time of h' is before the beginning 
time of A, then h' prepares for A. 

It is easy to see that the son correlation method can find all pairs of hyper- 
alens such that the first prepares for the second. Consider two hyper-alerts A 
and h' where A' prepares for A. There must exist an instantiated predicate pm 
both (he expanded consequence set of k' and the prerequisite set of A. Thus, 
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p along with hf must be placed in the array v4con» P ‘Jtmg with h must be 
placed in the array Apr^. The scanning meth<xl (lines 9-16} will eventually 
pc^int i to p’s block in Aprt j P'S block in Aeon same time, and 

output V prepares for h. Therefore, the sc^rt correlation can discover all and 
only pairs of hyper-alerts such that the first prepares for the seex^nd. 

We also study the possibility of adapting two-indexjoin and hash join meth- 
ods [7] to improve the performance of batch alert correlation. However, our 
analysis indicates they cannot outperform nested IcKip coireladon due to the 
fact that alert correlation is performed entirely in main memory, 

A naive adaptation of two-index join leads to the following method; Build 
two index structures for the instantiated predicates in the prerequisite sets and 
the expanded consequence sets, respeedvely, Rweach instantiated predicate p, 
locate the hyper-alerts related to p in both index structures, and compare the 
correspK^nding timestamps. However, this method cannot perform better than 
the nested loop method. The nested loop method only involves insertion of 
instantiated predicates in the expanded cx^nsequence sets and search of those 
in the prerequisite sets. In contrast, the above adaptation requires insertion 
of instandated predicates in both prerequisite and expanded consequence sets, 
and search of instantiated predicates in at least one of the index structures, 

A possible improvement over the naive adaptation is to merge the two in- 
dex structures. We can associate two sets of hyper-alerts with each instantiated 
predicate p, denoted /fpr«(p) and^c 0 n(p)» build one index structure for the 

instantiated predicates, Hpreip) ^wn(p) <-'<'nsist of the hyper-alerls that 
have pin their prerequisite sets and expanded cx^nsequence sets, respeedvely. 
After all the instantiated predicates in the prerequisite or the cxwsequence set 
of the hyper-alerts are inserted into the index structure, we can simply scan all 
the instantiated predicates, and compare the correspx^nding timestamps of the 
hyper-alerls in Hpreip) each instandated predicate p. How- 

ever, each insertion of an instantiated predicate entails a search operation, since 
the corresponding hyper-alert has to be inserted into either if pre(p) hup). 
Thus, this method cannot outperform the nested ItKip method, which involves 
one ircsertion for each instantiated predicate in the expanded consequence sets, 
and one search for each instantiated predicate in the prerequisite sets. A similar 
conclusion can be drawn for hash join. 

Another possibility to have a faster batch coirelalion is to use Chained 
Bucket Hashing. Siru:e the number of alerts is known beforehand, we may 
be able to decide a relatively accurate hash table size, and thus have a better 
performance than its counter part for streamed alerts. We study this through 
experiments later. 
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3.3. Correlating Intrusion Alerts with Limited Memory 

The previous approaches lo in-memory alert correlation have assumed chat 
all index structures fit in memory during the alert correlation process. This may 
be true lor analyzing intrusion alerts collected during several days or weeks; 
however, in typical operational scenarios, the IDSs produce intrusion alerts 
continuously and the memory of the alert correlation system will eventually 
be exhausted, A typical solution is to use a “sliding window” to focus on 
alerts that are close to each other; at any given point in time, only alerts after a 
previous time point are considered for correlation. 

We adopt a sliding window which can accommodate up to t intrusion alerts. 
The parameter i is detennined by the amount of memory available to the intru- 
sion alert correlation system. Since our goal is to optimize the intrusion alert 
correlation process, we do not discuss how to choose the appropriate value of 
t in this paper. Each time when a new intrusion alert is coming, we check if 
inserting this new alert will result in more than t alerts in the index structure. 
If yes. we remove the oldest alert from the index structure. In either case, we 
will perform the same correlation process as in Section 3,2 It is also possible 
to add multiple intrusion alerts in batch. In this case, multiple old alerts may 
be removed from the index structure. Note that though choosing a sliding time 
window is another option, it doesn’t reflect the memory constraint we have to 
face in this application. 

Using a sliding window in our application essentially implies deleting old 
intrusion alerts when there are more than t alerts in the memory. This problem 
appeared to be trivial at the first glance, since all the data structures have known 
deletion algorithms. However, we soon realized that we had to go through a 
little trouble to make the deletion efficient. The challenge is that the index 
structures we build in all the previous approaches are in terms of instantiated 
predicates to facilitate correlation. However, to remove the oldest intrusion 
alerts, we need to locate and remove alerts in terms of their timestamps. Thus, 
the previous index structures cannot be used to perform the deletion operation 
efficiently. Indeed, each deletion implies a scan of all the alerts in the index 
structures. 

To address this problem, we add a seamdary data structure to facilitate 
locating the oldest intrusion alerts. Since the intrusion alerts are inserted as 
well as removed in terms of their time order, we use a queue (simulated with 
a circular buffer) for this purpose. Each newly inserted intrusion alert also has 
an entry added into this queue, which points to its location in primary index 
structure in terms of the instantiated predicates. Thus, when we need to remove 
the oldest intrusion alert, we can simply dequeue an alert, find its location in 
the primary index structure, and delete it directly. Indeed, this is more efficient 




Adapting Query Optimization Techniques for Efficient Alert Correlation 



85 



lhan ihe generic deletion method of the order preserving index structures (e.g., 
AVL Trees), since deletion usually implies search in those index structures. 

4. Experimental Results 

We have implemented all the techniques discussed in Section 3 in Java, 
with JDBC to connect to the DBMS. We performed a series of experiments to 
compare these techniques. All the experiments were run on a DELL Precision 
Workstation with 1.8GHz Pentium 4 CPU and 512M bytes memory. The alerts 
used in our experiments were generated by a RealSecure Network Sensor 6,0 
(http: //www. ias . net), which monitors an isolated network in which we 
replayed the network traffic collected at the DEF CON 8 CTF event. We sum- 
marize the results in this section; further details can be found in (12], 
Neslal-Loop Correlalion without Memory Constraint. Our first set of 
experiments is intended to evaluate the effectiveness of hyper-alert container 
in nested loop correlation. According to our analysis, hyper-alert container 
may reduc*e the execution time if we use the order-preserving index structures. 
We compared the execution time for Sequential Scan, Array Binary Search, 
and Linear Hashing, with or without hyper-alert container. Our results show 
that hyper-alert containers reduce the execution time for Array Binary Search, 
but increases the execution time for Sequential Scan significantly, and Linear 
Hashing slighdy. Figure 4(a) shows some results obtained in the experiments. 

Our second set of experiments is to evaluate the effectiveness of tw<vlevel 
index structure in the nested l(x>p correlation meduxJ, Our results indicate that 
two-level indexes reduce execudon time for all index structures. Figure 4(b) 
shows the improvement of tw<vlevel index for B Tree and Linear Hash. 

Our next goal is to find out which index structure (with or without the two 
adaptations) has the best performance for nested loop correlation. Our results 
show that tw<vlevel Linear Hashing (without hyper-alert container) achieves 
the best performanc*e. Figure 4(c) shows the top three fastest meduxls, two- 
level Array Binary Search with hyper-alert container, two-level AVL Tree, and 
two-level Linear Hashing, 

Batch Correlation without Memory Constraint. Our evaluation here is 
to determine whether any meduxJ can achieve better performance than nested 
loop correlation with tw<vlevel Linear Hashing, the best method for correlating 
streamed alerts. Besides two-level Linear Hashing, we tested Chained Bucket 
Hashing and the sort cx>neladon methods because of their potential to outper- 
form tw<vlevel Linear Hashing. To further examine the impact of the time 
order of input hyper-alerts, we examined the timing results with ordered and 
unordered input (in terms of their timestamps). With unordered input, an algo- 
rithm must insert all of the instantiated predicates in the expanded consequerwe 
sets before it prcx;esses any instandated predicate in the prerequisite sets. 
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Figure 4(d) shows the liming results of these methods. Surprisingly, Chained 
Bucket Hashing has (he worst performance. Our further invesiigaiion reveals 
that there is a highly uneven distribution of hyper-alerts in the buckets, which 
lead to this bad performance. Having ordered input only reduces the execution 
time slightly for nested loop correlation with both two-level Linear Hashing 
and Chained Bucket Hashing. Finally, sort correlation with heap son achieves 
the best performance among these methods. 
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We also study the impact of different sorting algorithms on the execudon 
time of sc^rt correlation. We cx^mpare two sorting algorithms, heap sort and 
quick sort. Heap sort has the least cx>mplexity in the worst case scenarios, 
while quick sort is considered the best practical choice among all the sorting 
algorithms [4). Figure 4(e) shows the timing results of both algorithms: S<^rt 
cx^nelation with quick sort performs significantly worse (and most unstable) 
than the heap sort case, 

Nested-Lxwp Corraialion with Memory Constraint. Our last set of exper- 
iments is focused on evaluating the efficiency of different indexing structures 
when there is memory constraint. The results indicate that two-level Linear 
Hashing is the most efficient and the two level index structure improves the 
performance for all four methods. Figure 4(f) shows sc^me timing results ob- 
tained with varying sliding window sizes, 

5. Related Work 

The result in this paper is a condnuance of our previous work [11], which 
has been described earlier. Our method was initially developed to address the 
limitations of JIGSAW [14], Our method has several features beyond JIGSAW, 
including the ability to deal with missing detections and alert aggregation. The 
work cUisest to ours is the alert correlation method by Cuppens and Miege 
[5], This approach also cx>rrelales alerts using partial match of prerequisites 
(pre-cx>nditions) and consequences (post-conditions) of attacks. However, our 
method allows alert aggregation during and after correlation, while their ap- 
proach treats alert aggregation as an individual stage before alert correlation. 

Several other alert cx^rrelation methods have been proposed. Spice [13] and 
the probabilistic alert correladon meth^xl [15] correlate alerts based on the sim- 
ilarities between alert attributes. Though they are effective in correlating scTOe 
alerts (e.g., alerts with the same sc^urce and destination IP addresses), they can- 
not fully discover the causal reladonships between alerts. AnotJier type of alert 
cx^irelation methtxls (e.g., the data mining approach [6]) bases alert correlation 
on attack scenarios specified by human users or learned through training data 
sets. These methods are restricted to known attack scenarios. We consider 
these results complementary to ours. 

6. Conclusions and Future Work 

In this p^^er, we studied main memory index structures and database query 
optimization techniques to facilitate timely cx^rrelation of intensive alerts. We 
developed three techniques rvdmed hyper-alert container, two-level index, and 
sort correlation by taking advantage of the characteristics of the alert cor- 
relation process. The experimental study demonstrated that (1) hyper-alert 
containers improve the efficiency of order-preserving index structures, with 
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which an insenion operation involves seaich, (2) cwo-Jevel index improves the 
efficiency of all index siruciures, (3) a iwo-level index structure combining 
Chained Bucket Hashing and Linear Hashing is most efficient for screamed 
alerts with and without memory constraint, and (4) sort correlation with heap 
son algorithm is the most efficient for alen correlation in batch. Our future 
work includes incorporating the efficient methods in this paper into the in- 
trusion alen correlation toolkit and developing more techniques to facilitate 
timely interactive analysis of intrusion alerts. 
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Absiraci: Privacy concern.^ have become an impcnani Issue in Daia M Ining. This paper 

deal with (he problem of a&sociadon rule mining from distributed verlicaJly 
partliioned data with the goal of preserving (he confidenilali(y of each 
Individual database. Each site holds some aiiribu(es of each (ransacilon, and 
(he sites wish to work together to find globally valid association rules vrithout 
revealing individual transaction data. This problem occurs, for example, when 
(he same users access several electronic shops purcha.sing different items in 
each. We present ivro algorithms for discovering frequent Item sets and 
analyze their .security, privacy and complexity properties. 

Key words; item set. association rule, privacy 



1. INTRODUCTION 

Daia mining technology has emerged as a means for identifying patterns 
and irends from large quantities of data. Mining encompasses various 
algorithms such as clustering, classification, and association rule mining. 
Traditionally, all these algorithms have been developed within a centralized 
model, with all data being gathered into a central site, and algorithms being 
run against that data. Privacy concerns can prevent this approach. There may 
not be a central site with authority to see all the data, or if the data is 
partitioned among several sites, sites may not want to disclose to each other 
their individual database, even if they arc willing to disclose some 
information in order to enable the extraction of globally valid knowledge. 
Clearly if all participating sites are willing to share their data, or trust a third 
party to do the mining, the privacy problem is solved. We deal here with the 
problem that each site tries to protect the confidentiality of ils database. 
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without compromising most of the knowledge discovery process. Informally, 
the problem is to mine association rules across two databases, where the 
columns in the table are at different sites, splitting each row. The problem 
was first discussed by Vaidya and Clifton in [3] (called here VDC). Their 
algorithm requires the intensive use of secure computation and may also have 
the potential of inferring some information of the individual databases, as 
will be discussed in Section 2.2. and this motivated our algorithms. 
Generally, the mining of association rules is divided into two phases: finding 
frequent item sets with support above a threshold, and finding rules with 
confidence above a threshold . In this paper we present two algorithms for 
solving the first problem. The problem of computing the rules can be solved 
similarly but is not addressed in this paper. The first algorithm is a two-party 
algorithm which requires a third party, but may also work instead with secure 
computation. The second is an asymmetric n-party algorithm, which docs not 
require a third party or secure computation. In our protocols, one database is 
designated the master, and the initiator of the protocol, the other database is 
the slave. There is a join key present in both databases and the remaining 
attributes are present in one database or in the other, but not in both. The 
algorithms are based on two basic ideas. The first idea is the use of fake 
transactions. In spite of the existence of fake transactions it is possible to 
compute conectly the frequent item sets. The second idea is not to fix a 
precise measure of support but rather an approximate jneasure only, which 
can be jnade as precise as needed with a trade-off of the potential amount of 
infened private infortnation. 

The rest of the paper is structured as follows. Section 2 presents the 
background and related work. In particular. Section 2.1 reviews the secure 
computation of a scalar product of two vectors (based on [6]), which we shall 
use in our algorithjn for computing secure intersection of two sets, and 
Section 2.2 reviews the VDC algorithm [3| and discusses its potential 
problems. Section 3 presents the two algorithms, and some examples of their 
use. Section 4 discusses the privacy, security and complexity of the 
algorithms, and Section 5 is the conclusions and future work section. 



2. BACKGROUND 

Agrawal and Srikant [1] have proposed the first algorithm for discovering 
all significant association rules between items in a large database of 
transactions. However, this work did not address privacy eoneems. Later the 
authors proposed a procedure in which some or all the numerical attributes 
are perturbed by a randomized value distortion, so that both the original 




Collahoralive Privacy Preserving in Vertically Partitioned Databases 



93 



values and ihcir disihbulions arc changed. The proposed procedure then 
performs a rcconslruclion of the original distribution. This reconstruction 
does not reveal the original values of the data, and yet allows the learning of 
decision trees. Another paper shows a reconstruction method, which docs not 
entail information loss with respect to the original distribution. 

When the data is partitioned among several sites, there arc algorithms that 
assume that all required data is available or can be sent to a central site. Then 
the existing data mining algorithms for centralized data mining model arc 
executed. Another approach for distributed data mining runs the existing data 
mining algorithms for centralized data mining model at each site 
independently and combines the results [2]. But this will often fail to achieve 
a globally valid result. As pointed in [3). The issues that can cause a disparity 
between local and global results include: 

a) Values for a single entity may be split across sources. Data mining at 
individual sites will be unable to detect cross-site correlations. 

b) The same item may be duplicated at different sites, and will be over- 
weighted in the results, 

c) Data at a single site is likely to be from a homogeneous population, 
hiding geographic or demographic distinctions between that population 
and others. 

To overcome the above problems, algorithms were proposed for 
partitioned data between sites. The algorithms that were proposed for 
horizontally partitioned data (i.e, each site contains basically the same 
columns). Some of them use cryptographic techniques to minimize the 
amount of disclosed information or a special architecture. This architecture 
contains sites that sequentially add noise to the original data, compute the 
answer with noise and remove the noise from the answer. All these methods 
work with the assumption that no collusion occurs between the sites and the 
sites follow the protocol precisely. 

The main work on vertically partitioned data is that by VDC [3], which 
we will discuss later in this section. 

There has been much work addressing Secure Multiparty Computation. It 
was first investigated by Yao[4], and later, after Goldriech proved existence 
of a secure computation for any function[5| some algorithms based on his 
Circuit Evaluation Protocol have been proposed. But the general method, 
which is based on Boolean circuits, is inefficient for large inputs. Atallah and 
Du [6| proposed a more efficient technique for some ca.ses of multi-party 
computation problem. One of them is the Two-Party Scalar Product Protocol. 
VDC uses a similar but more efficient protocol for secure product 
computation as the basis for their algorithm for privacy preserving 
association rules mining [3]. We will discuss this in more detail later. 
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This paper uses the general approach suggested by VDC, but proposes 
two new algorithms to dcaJ with vertically partitioned data. It also docs not 
provide a zero- knowledge solution, but it discloses less amount of 
information than (3), and may be more practical in some cases. 

2.1 M.J.Atallah and W.Du Scalar Product 
Protocol 

Inputs; Alice has a vector and Bob has a vector 

Outputs: Alice (but not Bob) gets A" ♦ K + V where v is random scalar 
known to Bob only, 

1 Alice and Bob agree on two numbers p and m, such that is so 
large that conducting additions is computationally infeasible, 

2 Alice generates m random vectors, Fi,..., P m, such that X- 

3 Bob generates m random numbers /*i such that v« 




4 For each j= 1,.... m Alice and Bob conduct the following sub- 
steps: 

4.1 Alice generates a secret random number 
k,l< k ^ p , 

4.2 Alice sends (H\, ,,,,//^ ) to Bob, where Hk ^ Vj, and the rest 
of Hi ’s arc random vectors. Because A: is a secret number 
known to Alice only. Bob docs not know the position of Vj . 

4.3 Bob computes Zjj ^ Hi • Y +ry for i = l„..,p . 

4.4 Using the 1-out-of-N Oblivious Transfer protocol [8.9], Alice 
gets Zj ^ Zi‘‘‘ “ ^ • K + r,, while Bob learns nothing about k. 

5 Alice computes u * ^Z/ ^ X • Y + V 



As we’ll see in Section 3, we could use the above algorithm to compute 
the size of the intersection of two sets, however a straightforward use by 
using binary vectors as membership vectors is not secure enough. This will 
be explained further in Section 3.1, 
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2.2 The VDC algorithm [3). 

The algorithm uses the apriori-gen function to generate all candidate 
itemsets. For each found itemset, the algorithm calculates the support as 
follows: 

Lt * (large 1 -itemsets) 

for (k =2; ++) do begin 

Cl «=apriori*gen( • i ) 
for all candidates c e G do begin 
if all attributes in c are entirely at A ox B 
that party independently calculates c£ouni 
else 

let A have / of the attributes and B have the 
remaining m attributes, 
construct X on A' ^ side and K on 5 's side 
where ^ = fj /<, and y = fj", B. 
compute c£Ount x • y. 

end if 

Lt “ c\c£Ounl Sminsup 
end 

end 

Answer * u * 

Suppose wc want to compute if a particular 5-itcmsct is frequent with site 
A having 2 of the attributes and site 5 having 3 attributes, i.e, A and B 
want to know if the itemset / AA^Ab,B<i, Bt, Be} is frequent. A creates 
a new vector Xof cardinality « where X ~ An • /I > (component 
multiplication) and B creates a new vector ¥ of cardinality n where 
Y ^ Bn* Bb* Be . The Scalar product of X and Y provides the (in)frcquency 
of the itemset . The scalar product is computed using a different method of 
secure computation than the one presented in [6]. As wc'il see later wc use a 
minor modification of the algorithm in [6|, but we could have used the 
method of [3] as well. 

The VDC algorithm has some problems. First the method requires 
communication of the two sites, for each item set computation. As wc shall 
see, this is not required in our algorithm. The second problem is that this 
method may disclose information in certain eases, because in this algorithm 
each site learns the exact support of each item set. This is explained next. 

Assume that site A learns the exact support for some itemset. With this 
knowledge, A learns the probability that an item in the set supported by A 
has a property in 8, computed as the ratio of the actual support to A’s 
support. For example, in the ease when wc have a support value of 5% for an 
itemset ah. and exactly 5% of the items on A have item a, A knows that at 
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leasl those same items on B have property b. This occurs always when the 
global support equals A ’s support, not just when A '% support is at the 
threshold. 

As we shall see, our algorithm discloses such information in less number 
of cases. Only when the global support is exactly equal to the threshold and 
to one of the parties’ support value, it discloses the same amount of 
information as VDC, When the global support value is larger than the 
threshold, it discloses less information than VDC, and when the support 
value is less than the threshold, it discloses almost no information. 

3. THE ALGORITHMS 

We first present the definition of the problem, and the ideas, which are 
common to both algorithms and then, the two algorithms. 

The association rule mining problem can be formally stated as follows 
[7]: Let / = be a set of literals called items. Let D be a set of 

transactions, where each transaction T is a set of items such that T ^ I . 
Associated with each transaction is a unique identifier, called its TID. We 
say that transaction T contains X, a set of some items in / , if A" £ T . An 
association rule is an implication of the form, A ^ K, where A* c/, 
K C / . and X r\Y ^ ^ . The rule X holds in the transaction set D 
with confidence c. ifc*^^; of the transactions in D that contain Jf also contain 
y. The rule X ^ V has support s in the transaction set D. if s% of the 
transactions in D contain X kj Y . Item set X is called large if its support is 
greater then or equal to the minimal support threshold. Our goal is to find all 
large itemsets (as noted in the introduction, the problem of finding the rules 
can be solved similarly, but is outside of the scope of this paper.). 

In a vertically partitioned database we have the following situation. There 
are two databases. DBl and DB2. In both databases, the domain of the l lDs 
is the same. We are only interested in large item sets, which contain 
attributes from both databases. In both databases there are llDs which are 
not present, however for those llDs which are not null, llDs (DBI) rs 
TIDs(DB2) is close to sizc(DBi). which enables a real-life mining of globally 
frequent item set. The problem is to find large item sets without each site 
revealing its own database. 

Both algorithms follow the basic collaborative Apriori algorithm. 
However, before applying the algorithm there is a pre-processing stage that 
populates the individual databases with fake transactions. After this action, 
each party can send the resulted database to the opposite party to calculate 
the frequent itemsets in the resulted database. In the first algorithm the two 
parties are symmetric. In the first phase one is designated as a master, which 
initiates the protocol and will get the results, and the other as a slave, which 
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only contributes its information but will not do any global computations. The 
master is looking for all large itemsets according to its own real transactions, 
and check whether the found itemsets arc present in the slave real 
transactions. This is done with the help of a third untrusted party (this party is 
not trusted with the database, but it is trusted with computations). The parties 
change roles at the end of the phase. 

In the second algorithm, there arc n slaves and one master. The master 
computes the globally valid item sets and tells the results to the slaves. 

We assume without loss of generality that the number of transactions in 
each database is equal to N - some number that depends on area of business, 
and the TIDs range from 1 to N. When fake transactions are introduced, they 
use "unoccupied" TIDs. When information between the parties is shared, 
then only information in which some attributes are real (in one of the 
databases) is of use. That is, a fake transaction whose corresponding TID in 
the other database is empty, is not considered at all. Its important to note that 
when each site computes large itemsets it doesn’t know whether the 
attributes corresponding to his real transaction, arc real or not! 

3.1 Algorithm 1 

Preparing phase (executed by two parties): 

1 Construct database with fake transactions (Simply put randomly 1 in 
non existing transactions), 

2 Send to the third Party all your real TID, 

3 Receive from third Party whether mining is possible (See the Third 
Party execution phase). If it is then continue. 

4 Send the database from one party to the opposite party and receive its 
database. 

5 Build the global database (TIDs from step I, and attributes from the two 
databases). 

6 Build local true database (LTDB • contains the local real transactions 
only, but with possibly fake attributes from the other party). 

Master's Execution phase: 

1 find ZXi - all large 1 'itemsets in the local database from 6. 

2 for each I € LL : 

2. 1 send LID = {TID | / present in transaction 

with id « TID) to third Party 

2.2 receive from third Party Ok or Not 

3 end 

4 OL ' { / € LL> I third Party said Ok} 

5 for(^:*2; GL - , 
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5 J C = apriori -gen ( GL ■ > ) 

5.2 for all transaction / e LTDB 

5 .2. 1 C = subset( C . / ) 

5.2.2 for all candidates c € C 

5.2.2. 1 CMunt+^ 

5.2.3 end 
5-3 end 

6 LL.- Ice Ci \c£ount >mtnsup| 

7 for each leu. 

7.1 send LID » jTID | I presents in 

transaction with id = TID) to third Parly 

7.2 receive from third Party Ok or Not 

8 end 

9 GLi * { / e LL. I third Party said Ok} 

10 end 

1 1 send to third Party “Master Finished” 

12 Answer * u* 

1 3 reverse roles and execute algorithm again 
Third Party execution phase: 

1 receive from the two parties their real TID (TIDI,TID2) 

2 send to the two parlies (ITIDI TID2f 2: minsup) 

3 if(|TIDlnT[D2|> minsup) 

3. 1 while (Master not finished) do 

3.1.1 recci ve set of TID ’ s from Ma ster 
(MTID, |M1'ID| S minsup) 

3-1.2 if[|MTlbf^ TID2| > minsup] then 

3. 1.2.1 send "Ok” to Master 

3.1.3 else 

3. 1.3. 1 send “NotOK" to Master 

3.1.4 end if 

3.2 end while 

4 else 

4. 1 send "NotOK" /* mining is not possible! 

not enough overlap! •/ 

5 end if 

6 end 

Slave execution pha.se: 

) Execute preparing phase, 

2 Wait for master to finish. 
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3.1.1 Secure computation 

Instead of a third party, one may use secure computation. The main 
problem is overcoming the "0, 1” problem. Let us discuss it in more detail. 

To compute the intersection size of two sets of TIDs (from a common 
domain), one can use binary vectors where a 1 indicates membership and a 
zero indicates non-existence. The scalar product of these two vectors is the 
size of intersection. For example in Algorithm I . the master creates a vector 
X = such that X * 1 if transaction with ID *= i is a real 

transaction of the Master and contains the checking item set I, and x » 0 , 
if transaction number i is a fake transaction or does not contains an itemset 
/, and the Slave generates a vector Y ^ iy\ ,yi similarly. However, 

if one uses Attallah and Du‘s protocol [6| directly, there may be a 
compromise of information. This can be demonstrated as follows: 

Suppose one party knows some data values, the equations can be solved 
to reveal all values. For example, ifX is represented as Ki » (0,0,1), Vi ® 
(0,1,0), V} = (0,1,1), T *(1,1*1) and = 4, and the first party gets: 
yy + r, »7 
yi +r, =5 

Since y, was eliminated by the "zeroes", the first party now has 3 
equations with 3 unknowns. Which it can solve to disclose both the y's and 
the r. 

To reduce this possibility in our protocol, we can restrict the Master not 
use the value "0” in the representation of vector X, and for the Slave not to 
reuse the r-values sent once. 

The following method explain, how we can divide the vector X into 
m random vectors Fi , Fn : 



The Master generates m 



random vectors from such that X * 






Now, the Master and the Slave can perform a Scalar Product Protocol as 
is, to find the size of the intersection of vectors X and Y . For example, 
assume the Master creates vector A* ® (x^ ,Xt y...,Xi9)^(J,J.O.O.O.I.I,Oj,0) 
and the Slave generates the vector Y “ ) * 

Suppose the Master and the Slave agree on the number 
/n = 3 and p =1 1 in the protocol. Now, the Master generates following 
random vectors: 
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K-(2,3,4,5,5,7,8,9.l,10) 

F3 = (9,7A2.M0,8,5,2,2) 

Now, the Master and the Slave can perform a Scalar Product Protocol as 
is, to find the size of the intersection of vectors Xand Y without having the 
danger of eliminating Ys because of the “0”s. Note, that only the Slave 
knows the size of the intersection, and it can send to Master “Ok" if this size 
^minimal support. 

3.2 Algorithm 2 

In this algorithm we do not use a third party and instead let each slave 
compute the intersection itself. However, since the slaves have no knowledge 
of the other databases, their inference from this computation is very limited. 

We assume that we have one Master and n Slaves, The Master starts the 
computation with the first Slave and waits for the last Slave for a positive or 
a negative result. 

Execution phase for each Slave: 

1 receive a set of IDs (or “NOT OK”) from your left neighbour. 

2 if received “NOT OK" 

2.1 send “NOT OK” to your right neighbour. 

2.2 go to 1 

3 else 

3.1 intersects the set with your own real IDs and lest, 

4 if result ^ minimal support 

4.1 send resulted SetOflds to your right neighbour 

5 else 

5 . 1 send “NOT OK ’ ’ to your ri ght neighbor. 

5.2 go to I 

6 end if 

Now we can describe the algorithm, which is quite similar to 
Algorithm 1. 

Master’s preparing phase: 

1 Send to your right neighbor all real TlDs. Receive from your left 
neighbor whether mining is possible. If it is, then continue, 

2 Build the global database (TID * TIDl k^TrD2,... ^TfDn and the 
attributes from the n databases (i.e. each slave sends the database with 
fake transactions to the master). 

3 Build local true database (LTDB • contains the local real transactions 
only). 



Ma.slcr's execution phase: 
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1 find LL>- all large l-item&ets in local database from 4. 

2 for each / e ZX» : 

2. 1 LID = {TID I / present in transaction with id * TID) 

2.2 send LID to the right neighbor 

2.3 receive from left neighbor Ok or Not 

3 end 

4 GL\ ° { / € LL\ I Slave said Ok^ 

5 for ( ^ * 2; GL» v* ++) 

5.1 C*= apriori-genfGZrf - •) 

5.2 for ail transaction / s LTDB 

5.2.1 C “subsetCC./) 

5.2.2 for all candidates C € C 

5.2.2. 1 c,coww^++ 

5.2.3 end 

5.3 end 

5.4 LI . * {c e C \c.count Sminsup) 

5.5 for each I e LL. 

5.5.1 LID * {TID I / presents in transaction with id * TID) 

5.5.2 send LID to the right neighbor 

5.5.3 receive from left neighbor Ok or Not 

5.6 end 

5.7 GLt “{/ eiL, I Slave said Ok) 

6 end 

7 Answer” GL* 

8 send Answer to all Slaves 

Note that in this case wc may also use secure computation, but if the 
number of databases is greater than 2. this is not really necessary, since each 
slave may not be able to infer much anyway. This is because when n>2. each 
slave not only does not know the exact size of the final inlcrscclion, but also 
docs not know which exact item set the master is currently testing! 



4. ANALYSIS 

4.1 Correctness 

The two algorithms use the apriori-gen function to generate all candidates 
to be large ilemset. On each iteration k, a large k-ilem sets that was found 
by the Master according to its true transactions only, was cheeked by another 
site. So, all existed large ilemscls where found. 
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4^ Security analysis 

The security of the approach depends on the algorithm and the method. In 
algorithm 1 and a Third parly, il depends on the integrity of the third party. In 
algorithm 2, on the integrity of each of the slaves. 

If we use secure compulation, then the security of our approach is based 
on the security of the scalar product protocol, which is based on the inability 
of the slave side to solve p * m equations with n + m unknowns, which 
requires that n>m (p *1), Since the master does not get the result of the 
scalar product, just an “OK” answer, it cannot use the linear equations 
methods anyway. 

Computing support for each candidate item set requires one run of the 
component scalar product protocol. Again, the slave is secured by the same 
bound, since at each run the master sends it a different intersection set (with 
different random components). 

4.3 Disclosed information 

In both algorithms, neither the Master nor the Slave learns the exact 
support for an item set. They only know, whether some item set is frequent 
or not. This decreases the probability that the Master or Slaves will learn that 
a set of items on another site has a given properly and it occurs only when 
the global support value is above or equal to the threshold value, and is also 
equal to the Master’s or Slave’s support. For example, if a is an item from 
the Master's database, and b is an item from the Slave's database, the 
threshold support is 5%. and the global support is greater or equal 5%, and 
item set la.bj is present in exactly 5% of the real Master’s transactions, then 
the Master knows that the same transactions arc real transactions of the 
Slave, 

In the ease when the item set la.bj is present in more then 5% (support 
threshold) of transactions in the Master's database, say 7%, and fa,bl is still 
a global large item set. the Master knows, that al least 5/7 transactions of the 
Slave arc real transactions, but he is not sure even which are real transactions 
and which are fake. When the support of a tested item set is less than the 
support threshold, very little information is disclosed to the master and 
almost none to the slave. 

Note that the master in either Algorithm I or AIgorithm2 never knows the 
support value, whether we use a third party or secure computation. When we 
use secure computation, or in Algorithm2 with only 2 parties, the slave does 
know the exact value of support, but it cannot do anything with it since it 
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doesn't know which item set the master is currently testing! So knowing the 
size of the produet docs not give him much information! 

As was explained in Seedon 2,2, in VDC, in contrast, the Master leams 
the probability that an item in the set supported by Master has a property in 
the Slave’s database, computed as the ratio of the global 1 support to the 
Master's support, whether the Hem sei is frequeni or noi\ 

One important point that we want to stress here is that if the participants 
don't know the number of fake transactions, then this number has no effect 
on the amount of disclosed information. It can only affect the performance 
(redundant computations) of the algorithm! 

One problem which can occur in our algorithms, although unlikely, is that 
some specific value will be disclosed when the database has a large number 
of overlapping entities. For example, suppose the Master’s real IDs arc Im = 
(1,2, 3 ,4, 5 ,6), and the Slave’s real IDs arc /;*{!, 2, 3, 4} and minsupp = 4. 
Assume the Master asks the Sbve whether | /i A /j | S minsupp and gets 
answer ‘YES" (/i* subset of Im and /j ®(1.2,3,4,5,6}). Next question is 
whether |/i A /#|^ minsupp and he gets the answer “NO” (/ 2 - subset of 
Imand /j ={1,2, 3,5,6}). The Master can come to the conclusion that 
transaction with ID = 4 is a real transaction of the Slave, and at least 2 
transactions from { 1.2.3.5.6} arc fake. Allowing approximate answers as 
follows can reduce this possibility, 

4.4 The Support approximation method 

Let us assume that the Master and the Slave agree on ac - approximation 
coefficient. In both algorithms, whoever compute the intersection size, the 
third party or the slave, instead of checking whether it is greater or equal than 
the minimal support, it docs the following. It generates a random number c. 
such that (minsup • ac)^c ^minsup, and sends “Okey" to the Master if the 
size of above intersection St c. and "No” in the other case. 

Now, for every tested item set. this approximation will use a new value of 
c. Thus, even for overlapping item sets it will be quite difficult to discover 
facts such as demonstrated above. This property decreases the exactness of 
the solution, since it only guarantees that the support will be above minimal- 
support - ac, but it discloses less information to the opposite side, and 
decreases the ability of any side to guess the real transactions of the 
opponent. 

Using the above example, the Master cannot distinguish between the 
following two cases: 

C = 3 during the first intersection calculation and C = 4 during the second 
intersection calculation when (1,2.3) arc real transactions of the Slave. 
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C = 2 during the first intersection calculation and C = 3 during the second 
intersection calculation when {1,2) are real transactions of the Slave, 

On the other hand, if the Master asks the Slave the same question a large 
number of times, it increases its chance of guessing the correct size of the 
intersection. This since if ac is not large, the average result will give out 
some information. To reduce this possibility, we can restrict the Master to 
check each set only once. 

5. CONCLUSIONS AND FUTURE WORK 

We presented two algorithms for discovering all large item sets in 
vertically distributed databases, without the sources revealing their individual 
transaction values. We compared these algorithms to the previously known 
algorithm by Vaidya and Clifton [3] and show that it is possible to achieve 
good security and privacy with complexity cost small enough. 

In the future, we will develop precise algorithms for producing rules and 
not only frequent item sets. We also plan to further investigate the 
privacy/performance tradeoffs both analytically and experimentally and test 
these tradeoffs with different support values. 
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Abstract This paper explores the possi bi I ity to represent ihe privacy polic ies of an i ndi v id- 
ual. as well as the processing steps of (hose who (concurrently) process the data, 
using a simple process algebra. FSR The approach leads lo ihe identificaiion of 
iwo major classes of privacy policies: aggregation policies and quantitative poli- 
cies. Automated analysis (with the LTSA tool) of such policies, in combination 
wii h Ihe actions of parties ihat proce.ss personal informal ion al lows ihe automated 
discovery of possible breaches of privacy. 

It is demonstrated that addressing the breaches often involves tradeoffs, such 
discontinuing interaction with some parties, so that policies are no longer violated. 



1. Intnxluction 

Persona] privacy has. in some respects, been an evasive topic in Computer 
Science, While it has become entrenched in. phrases such as Security and 
Privacy, it is often difficult to establish privacy adds to the notion that 
is not already covered under the rubric of security. The one clear exception is 
the association between privacy and anonymity: If privacy is a form of security 
for the individual, then anonymity guarantees privacy. Anonymity, however, 
is not a panacea; Not only are anonymity and accountability incompatible, but 
a tradeoff between anonymity and privacy implies a tradeoff between privacy 
and freedom — freedom of speech |23] and freedom to act; the degree to 
which actions and utterings can be observed, stored and matched in a digital 
environment would constrain such actions to a significant extent if one's only 
option to perform them with a reasonable amount of privacy were to perform 
them anonymously. 

Having said this, it is important to realise that sharing of personal informa- 
tion with others always carries some risk. There are very few guarantees that 
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personal information, once shared, will be treated in confidence and used in 
the manner in which it was intended. This risk is not without benefit, however: 
society depends on information about individuals being available. Society's 
need for accountability justifies individuals carrying identity cards and pass* 
ports. This need justifies the requirement that cars are fitted with licence plates. 
This need also justifies (responsible) use of blacklists for services where in* 
dividuals moved outside society’s reasonable expectatioas of how individuals 
should behave under certain circumstances. 

If total anonymity (for total privacy) is not the only option, the question 
becomes one of how much privacy can be achieved by how much reserve? 
Unfortunately, privacy and reserve (with many other such notions) are notori- 
ously difficult to quantify. It seems that the best approximation to this is some 
(formal) model that enables one to reason about specific tradeoffs. 

P3P (29| provides a first step in this direction. P3P allows both the user and 
the service provider to represent (a.spects of) their privacy policy. These policies 
are then compared and. only if the policies are compatible, is the individual's 
information shared. No attempt, however, is made to correlate information 
shared with a number of parties. Arguably, when multiple parties are involved, 
privacy risks for the combined case are significantly higher than the sum of the 
individual risks. This is amongst others due to the possibility of correlating 
(‘matching’) and aggregation of information by the various parlies. 

This paper explores the possibility to achieve some indication of the trade- 
offs that occur when an individual interacts with multiple parties and wishes 
to maintain privacy according to some personal policy. The activities of par- 
lies with whom an individual deals arc formally modelled. Next, the activities 
that have privacy implications are highlighted using the same formal modelling 
technique. Finally, the individual’s privacy policy is represented using the same 
technique. In this privacy policy undesirable slates are indicated. Reachabil- 
ity analysis is then used to check the possibility of reaching such undesirable 
privacy stales. The individual can now decide how to react to such a possible 
breach of privacy. 

A simple process algebra, FSP |22|, is used to model the activities of those 
parties with whom the individual interacts and the individual’s privacy policies. 
The LTSA tool (22] is used to perform the reachability analysis. 

The approach followed in this paper still offers many challenges, not the Iea.st 
of which is the complexity of appropriately modelling something as intangible 
as privacy. This complexity will specifically impact on the possibility of prac- 
tical application of the proposed approach. This paper ha.s a more modest goal 
than attempting to give a comprehensive solution to the stated problem; its goal 
is rather to explore the notions involved in addressing the problem and thereby 
help set the stage for a solution (if a practical solution docs exist). 
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The paper is siructured as follows, Seclion 2 gives some background about 
privacy. Section 3 introduces modelling the actions of parties with whom the 
individual deals as well as the individual's privacy ptdicy. Next, section 4 uses 
reachability analysis to identify privacy policies and considers cx>urses of action 
the individual may pursue to address such problems, Secdon 5 lies up some 
loose ends after which section 6 cx>ncludes the paper, 

2. Background 

Privacy is a cx>mplex issue. This is already evident if one only f<x:u.sses on 
technical issues — the main cx>ncem of this paper. It seems that technical work 
has been done in five areas regarding privacy, namely anonymity, private com- 
munication, inference control, organisadonal safeguards and personal control. 
Each of these is briefly cxmsidered below. For an introduction to non-technical 
aspects of privacy see [4, 8, 9, 18, 23. 27, 31,40). 

Anonymity work in privacy is based on the fact that observadon of one’s 
actions in Cyberspace is easier, and records tend to persist for longer. Work 
done to achieve anonymity (or pseudonymity) include onion routing [13] and 
Crowds [30] — both of which hide the origin of messages flowing through a 
network — and anonymous proxies (such as web anonymizers and anonymous 
remailers (5,1 1,21)) — that hide the IP-address and other identifying details of 
the client from the server. In this regard, it is worth noting Chadwick’ s point (6) 
that anonymity is not only a bad idea on the Internet (due to its incompatibility 
with accountability), but also that most of these solutions actually provide a 
pseudonymous solution. 

The second area — privacy of personal cx>mmunications — has primarily 
been addres.sed by encTypdon, This is evidenced by, for example, the name of 
the popular encryption product. PGP: Pretty GtkxJ Privacy (12). 

The third aspect of (technical) privacy that has received some attention is 
that of statistical inferenc'e. This has been achieved by modifying data in ways 
that are statistically insignificant [35] and by limiting statistical queries over 
such data to queries that include a sufficient number of entries so that inferences 
cannot be made about individual cases [7] and removing identifying information 
from such entries [33, 36]. In the last case, it is interesting to note that removing 
obviously identifying information (such as names, identity numbers, etc) is not 
sufficient and a more extensive sanitising of data is required [33. 36]. 

In the case of organisadonal safeguards, most work done on security is rele- 
vant. but not specific to privacy. Specific privacy safeguards will focus on pro- 
tection of the individual's information against Inadvertent (or even intentional) 
misuse by the organisation or those associated with the organisadon. It may 
be ^proached by implementing checks and balances to ensure that personal 
information is not misused. This can. amongst others, be ensured by recording 
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ihc purpose for which personal data has been eolleetcd. recording the privacy 
policy ^plicable at the time of data collection, recording personal preferences, 
and other similar privacy-related information. Additionally, an access moni- 
tor then controls all acces.ses to such data by ensuring that jkccss attempts arc 
compatible with all the security information recorded earlier, as well as other 
privacy considerations at the time of collection and/or at the time of use. A 
number of solutions to achieve this have been proposed [3. 10, 19. 1. 2. 20, 26], 
A common reservation about such solutions is the doubt that businesses will 
voluntarily implement them. The business case for such solutions have been 
argued in a number of places [2, 14, 15. 16. 17. 20. 23, 28, 39]. The essence 
of these arguments is that these technologies make business sense because they 
will help to attract customers and to build a relationship of trust with new and 
existing customers, yielding a (mutually) beneficial associasion. Such tech- 
nologies can also help to prevent costly privacy-related accidents. Products 
that have been introduced in this area include IBM’s Tivoli Privacy Manager 
[38] and PrivacyRight's TrustFilter [28]. Note should also be taken of IBM’s 
Enterprise Privacy Architecture [15, 19], 

The importance of organisational safeguards for the current paper is the fact 
that they provide a degree of assurance that organisations will indeed honour 
their privacy commitments as expressed in their privacy policies. When such 
technologies are properly installed and regularly audited, personal control be- 
comes more dependable. 

The final privacy aspect to be addressed here is indeed that of personal control. 
The best-known example here is P3P [29] where the individual controls whether 
information should be divulged to an organisation, given the organisation's 
privacy policy. Also in this category is the work done by Tcepc et aJ [37] 
that establishes what information an individual will need to divulge during the 
course of a workflow process before the individual initiates the workflow. This 
enables the individual to know whether participation in a workflow will become 
too sensitive, before divulging some private information as part of a process. 
The current paper also addresses this aspect (personal control) of the privacy 
problem. 

The relationships between the technologies considered above has been inves- 
tigated elsewhere [24], where it has been shown that a fully ordered relationship 
exists between them, that was then formalised as the Layered Privacy Archi- 
tecture (LaPA). 

The use of a process algebra to model aspects of security is not new [32]. 
Also privacy (specifically anonymity) has been modelled using aproccss algebra 
[32, 34]. In these ea.scs, the goal is to model security protocols and determine 
whether specific security properties (secrecy, authentication, non-repudiation 
and anonymity) hold for these protocols as required. In our case it is not security 
protocols that will be modelled, but business processes. Wc will also not be 
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primaiily cxwcemed about whether specific properties hold, but whether an 
arbitrary (user-specifiable) privacy policy can be violated. 

3. Modelling actions and privacy 
3.1. Behaviour of parties 

If the actions of some party with whom an individual wants to interact are 
known, it is relatively easy to model the aciions of that party in FSP. To illustrate, 
the actions of a shop may be 

SHOP ■ <addrM8.rttqvMSt •> pack -> ahlp •> addreaa. release *•> 

SHOP). 

Here the pack and ship actions are assumed to be primitives that have no 
real impact on the privacy of the individual. In contrast address . request 
and address .release are actions that were chosen to indicate that the shop 
acquires the customer’s address somehow and deletes it afterwards. 

Even the simple definition of a SHOP holds a number of challenges. Firstly, 
the question arises about who should define the actions of the SHOP, The end- 
user may not have access to the internal operadon of the SHOP and may therefore 
not be able to model the SHOP accurately, A better solution would therefore 
be for the SHOP to model its own actions and publish that as part of its privacy 
policy. This, however, would require a standardised nomenclature (or ontology) 
— a problem that we ignore given the explorative nature of this paper. A 
second problem introduced by the SHOP publishing its own actions as part of a 
privacy policy would be knowing which of its acdons are relevant for a diverse 
population of individuals, eiich with his or her own privacy policy. It is possible 
to address this by expecdng the SHOP to publish a relatively detailed account of 
its actions, and where the individual then selects only those that are appropriate 
to his or her privacy policy. The following FSP statement expresses that only 
address . request and address , release are relevant to the individual: 

SHOP ■ (addrflBfl .r»qu«Bt pack ship •> &ddr«88.r«leBBe •> 

SHOP) 

0^ address . {request , releaee)) . 

It is also pos.sible to model temporal retendon of data for audit purposes, as 
follows 

SHOP ■ (address . reqaaat •> pack '> ship *> vaicPiveYears *> 
address . release SHOP). 

However, this paper does not consider such temp<mal constraints. What the 
paper d<ws consider are ca.ses where information is retained until some action 
leads to its deletion. This is illustrated by the following definition of INSURER: 

XHSUREfl ■ (iDSuraacedata. request *> INSURQ^) , 
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IVSUHQ3 a (clAiJi *> process *> payout *> INSURED I 
cancel •> iQduraocedata, release ~> INSURER). 

Here ihe insurance data is retained until the policy is cancelled by an explicit 
cancel action, 

Rirthe sake of illustration below, one further class of organisations is intro* 
duced here: 

KARKETER « (address . request -> sendmail *> address release '> 
MARKETER) , 

Finally, the instances of these categories of organisations are defined and 
specified as processes that execute concurrently. For our purposes a and d are 
INSURERS, b is a SHOP and c is a MARKETER: 

U ORGANISATIONS * (a: INSURER II b:SH0P II c: MARKETER || 
dr INSURER). 

32. Categories of parties 

Now that the behaviour of parties has been specified, and some instances of 
those parties have been defined, it becomes possible to identify categories of 
organisations so that it will be possible to specify privacy policies in terms of 
such categories, rather than specific parties (although specification ofpnvacy 
policies in terms of such specific parties will not be precluded). 

The first category is one that inherently holds a negative connotation: 

SPAMKBt 9 (address. request •> epam •> SPAMMER). 

The intention here is that, whenever a party identified as a SPAMMER, performs an 
address .request action, it becomes possible for the SPAMMER process to 
perform the spam action, that will be used below in the policies section to 
specify a pnvacy policy to limit the actions of spammers. 

The second category to be used in this paper is not inherently value laden; it 
will be used to identify financial institutions and specifically identify the points 
at which they request and release information. FINANCIAL accomplishes this: 

FINANCIAL " ((addresB.tnauranced&ta) . requ«at -> finr«q '> 
{addres8,iaBuraBcedata}.r«ieA«« •> flnrel FINANCIAL). 

This definition incorporates a rudimentary form of categorising data: address 
is assumed to be part of insurancedata, and when either is requested, the 
f inreq (financial request) action becomes enabled. Similarly, when either is 
released, the f inrel (financial release) action becomes enabled. 

Unfortunately, given the nature of the process algebra used, these trigger 
actions (spam, finreq and f inrel) will automatically be enabled for those 
parties who are not placed in Ihe respective categories. (For example, if a is not 
identified as a SPAMMER in this section, a . spam will automaiically be enabled 
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in the policies section below, because there is no a . apam in the category section 
here (yet) for which it will have to ‘wait'.} In order to avoid this, it is necessary 
to intr<xluce \^)posites’ for the categories already introduced; 

N0T9PAHHEA - N0TSPAHHE21 . 

NOTFIBAHCIAL - KOTFmMCIAL ♦{flaziq, fiftrel}. 

In both of these cases the trigger actions do not form part of the prcK*ess de- 
scriptions but the alphabets of the processes are extended with these acdons; 
they therefore inherently cannot <x:cur in these proc'esses and will therefore not 
be enabled in the policies sec'lion below. 

All that remains in this section is to combine the various instances of parties 
with their respective categories. A possible combination looks as follows; 

IICATECOaiES • 

({«}:SPAHH^ II {a,b.4)rVCIT3PA)«CR II 
{a.d.b}; FINANCIAL II {ciilfOTPlNAHCIAL) 

33. Privacy policies 

Once the parties and categories have been modelled, the policies can be 
m<xlelled. 

In some cases (possible) <x;currence of the trigger action will violate privacy 
and therefore needs to be indicated as such: 

property CHECKS? AH - (spaa •> EKftOR). 

Another possible policy is to limit the number of occurTenc*es of one's infor- 
mation in different databases. The following policy limits one’s information to 
two financial institutions: 

co&et MaxPin • 2 

property CHECKPIN ■ CKECKFIMCOJ , 

CHeOKFlNtl:0..HaxFiB] - < 

when CKHazFia) floreq •> CHECKFIN[i<*-l] I 
wheo (l«*KezFin) fioreq •> BtAQA j 
when <l>0) flnrel -> CHECKPIN [i-l] I 
vben flnrel -> ERRGR). 

These examples suffice for the initial discussion and now it is possible to 
combine the various policies; 

set AllP7»c » ja,b,c,d) 

1 1 POLICIES • (AUProcr:CHECK8PAH II AllProc CHECKPIN) . 

Finally the parties, categories and policies can be combined; 

n SYSTEM • (OAGAKISATIONS II CATEGORIES II POLICIES). 
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4. Discussion 

A reachability analysis of the system described above can now be performed 
to see if the ERROR slate can be reached. If it cari. a trace to this state will 
illustrate how it is possible to violate the individuars privacy policy. As is dear 
from the simple examples given above, it is indeed p^tesible to violate the policy, 
A safely analysis with LTSA produces the following trace: 

2 ** States; 4 Irusitiona: 27 Maoory uaad: 7366K 
Trace to property vlcUtion Id PGLICIB2.<e,b,c,d>: :CKECKSPAH; 
e . addreae . re<)ueBt 
c epaa 

This indicates the (obvious) problem that the individual's CHECKS PAM policy 
can be violated if c requests the individual's address leading to the possible 
execution of the trigger action spam by c. 

This simple example illustrates one of the major points of this paper; Onc*e 
a fKxssible breach of privacy has been identified, it is, in general, up to the indi- 
vidual to deal with the possible breach. The individual may, for example, avoid 
the breach by no longer dealing with c. The individual may also invesdgate the 
reasons why he or she has identified c as a spammer. If it possible to accept the 
amount of junk mail c sends, it may warrant reclassifying c as a NOTSPAMMER. 
To further elaborate on this last point, suppose that b is classified as a SPAMMER, 
but in our agreed upon interaction (as specified by the FSP definition of b's 
behaviour) b does not send any mail. If we accept the specified descriptions 
as true of actual behaviour (a point that we already noted earlier in the paper), 
the individual may decide to phrase the SPAMMER category in terms of the mail 
action rather than (or in addition to) the address . request action, as follows: 

SPANNER - (laail •> apaai •> SPAMMER) . 



or 



SPAHMSt " Caddraas. request *> ual -> spaia •> SPANNER). 

Given such a trigger action definition, b would not violate the policy even if 
b were identified as a SPAMMER. In other words, thinking about the semantics 
of actions may lead to a redefinition of a trigger action or a privacy policy 
that would avoid the conflict. These opdons are in addition to the options of 
no longer dealing with the party involved in the breach of a privacy policy, or 
renegotiating the interaction with that party. 

Once the SPAMMER violation has been addressed in any of the above manners, 
a reachability analysis with LTSA leads to the following trace; 

D«pcb 6 — StatM: S70 Traoaitioos: S756 HDinory used: 8463K 
Trace to property violation In POLICIES. <a.b,c.d> : ;aiECKFIH: 

a . Inaur anc edat a . request 

b . address . request 
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d. l&Burancedata.r»qu«ftt 
ft.ilnxflq 
d. flareq 
b. fiDTBq 

Whal this shows is the (again obvious) result that the maximum number of 
financial institutions that are allowed to simultaneously hold the individual’s 
information can be exceeded (as illustrated here, when a. b and d simultaneously 
hold some of the individual's information). 

Resolving the violation may again be considered by stopping interaction 
with any of the parties involved (a, b or d). changing the categorisation (for 
example deciding that b is not a financial institution after all) or changing the 
policy (by. for example, setting MaxFin equal to three). For example, changing 
classification of b to NOT FINANCIAL yields the following safety results from 
LTSA: 

Diptb 26 — St&tve: 1S3M TruiBltlo&a: 93194 H«Bory ua»d; 8082K 
No deadXocke/«rcor» 

The question that needs to be addressed now, is one on the nature of privacy 
violations that can be modelled (and detected) using the approach described in 
this paper. While it is clearly possible to check privacy violations from a single 
party (such as that represented by the CHECKS PAM policy above) the clear power 
of the technique lies in detecting {and addressing) privacy violations that arise 
from the interaction of many parlies that are concurrently active and processing 
one’s data. Before turning our attendon to that, it is worth noting that single- 
party violations need not be as simple as the CHECKS PAM policy above: it is 
also possible to have apt>licy that monitor’s the party’s acquisition of personal 
information over time and flags the point at which the amount of collected 
information exceeds some threshold. Tbe details of how this can be done will 
be clear after the multi-party scenario has been discussed below. 

One type of privacy policy for which the described approach holds potential, 
is that of computerised matching. Suppose that some party m has access to the 
individual’s medical records, while another, t, has access to the individual's 
tax records. If the individual is concerned that m and t might use their access 
to match the data to learn more about the individual, the individual can set 
up a privacy policy that, while permitting the two parties to access his or her 
information, does not allow them to do it simultaneously. To do this, suppose 
that appropriate categories have been created to cause suitable medicalreq, 
medicalrel, taxreq and taxrel trigger actions. Then the following policy 
will specify the non-matching requirement: 

property CHECKHATCH ■ (taxreq -> HA8TAX I MdlealT«q -> 

HASHED) , 

KA3TAX - (taxTQl -> CHECKHATCH I Mdlcalr«q -> ERRON), 

HASHED •• (MdlcAlrel >> CHECKHATCH I tucreq -> ERROR) . 
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with POLICIES now defined as 

1 1 POLICIES - (AllProc:;OIECK5PiW If AllProc; :C»ECKFIN II 
;CHECKMATCH) , 

Prevention of computerised matching is dearly a speciaJ case of whai may 
be termed an aggregation policy — where the individual wanes to prevent si* 
multaneous processing of a set of personal data items that, when aggregated, 
may form a more comprehensive image of the individual (whether it is true or 
false) than the individual data items would have. Definition 1 formalises this 
notion. 

Definition 1 (Aggregation policies) Lei A he the .set of all personal attributes 
of an individual and ^ the set of all parlies with whom the individual interacts. 
Let A C ^ be a set of personal attributes about some individual. Let P C P 
be a set oftIu>se parties that occasionally process the attributes in A. Let 
proCilp) C A, with p € P indicate the set of attributes being processed by 
some party pat some instant i. An aggregation policy for A over P spedfie.s 
that no instant i exists for which 

[J prcfCi(p) = A 

P€P 

Note that the case where \P\ = 1 is the special case alluded to above when 
single -party policies were briefly considered. 

While the class of aggregation policies can indeed include a range of specific 
policies, it does not include the case that was used to introduce the modelling 
of properties above, where some financial information was limited to a specific 
number of instances or occurrences amongst a set of financial institutions. That 
case is formally defined in definition 2 

Definition 2 (Quantitative policies) Let A again be the set of alt personal 
attributes of an individual andPthe set of all parties with whom the individual 
interacts. Let A C A be some set of personal attributes and P C P some 
set of parties with whom the individual interacts. Let n > dbe an integer, A 
quantitative policy for A over P .specifies that 

\{p € PipTOCiip) n A 5 *^ 0}| < n 

where pTOCihas the same meaning it had in definition J. 

Again note that the ‘spamming policy’ used above is a special case of a 
quantitative policy for which n ^ 0. When n = 1 the privacy policy for 
a document implies that the document should be treated like a paper-based 
document: it could be at different parties, but not simultaneously. For n > 1 
(he choice of n in general seems to be arbitrary, with a lower value of n simply 
specifying a higher degree of privacy (with its concomitant costs). 
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5. Tying up loose ends 

One uf the fundamental assumptions of this paper is that is is possible to 
specify the behaviour uf parties with whom one interacts and then ‘know’ that 
they will slick to that behaviour. The notion that it is possible to specify real- 
world behaviour in a compact manner seems plausible but needs to be tested 
with real-world examples. This is, however, left to future research. 

The requirement that parties will stick to a given behaviour, once that be- 
haviour has been formalised in a policy, is also a complex issue, with psycho- 
logical. s<x;ial, ethical, technical and (possibly) other dimensions. This paper 
acc'epts that policies are routinely used to specify behaviour and that mecha- 
nisms exist in society to audit adherence to a policy and legal, societal and other 
sartctions can be used guarantee a reasonable degree of compliance. However, 
apart from the remarks made earlier about organisational safeguards, it is outside 
the scope of the current work to consider compliance with policies in practice, 

A more pressing issue for the current work is the nature of interaction 
specified in the pc^Ucies. Information was typically requested by some ac- 
tion (for example, address . request) and released afterwards (for example, 
address , release). The assumption was that data was to be provided when 
the request occurs and deleted later when the release occurs. This, however, 
does not accurately reflect practices in the real world. Since a customer database 
is an asset owned by a company, it is unlikely to destroy parts of it the moment 
it is no longer required for purposes of the transaction conducted. With the 
emergence of data mining the value of such data increases and the chances of 
voluntary deletion decreases. One possible route to explore is swial pressure 
to enforce deledon, which is a viable option if s<x:iety is indeed better served by 
such a practic*e than by permanent archiving — an aspect that is not explored 
in the current paper, 

A more viable approach seems to be the following: If parties who process 
personal information are willing to change their behaviour such that they send 
out a request to ptx;ess the information about an individual that they already 
have on rec'ord, it becomes possible to specify privacy policies in terms of not 
only data acquisition and release, but also in terms of processing. This would 
require the parties responsible to specify such px^ints in their behaviour where 
they start and stop processing data; in the case of a claim in our earlier example, 
behaviour might be :^>ecified as follows: 

INSURED ■ (cl&lB -> iDBurencBdat a. bBglQpro ceasing process •> 
payout insursncedsts. endproceasing •> INSURS) I 
c SAC el •> InauroAcedeta. release *> INSURER). 

While this approach is again against the spirit of the current paper, in that it 
expects a behaviour change from parties who pnxess information rather than 
only focussing on the individual's ability to control his or her private infor- 
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malion, this behaviour change clearly enhances the individual's possibililics of 
laking control: If this is implemented, the individual will be able to specify 
privacy policies much more precisely; computerised matching, for example, 
can be controlled even if a parly holds two pieces of information that should 
not be matched — simultaneous possession is less of a concern if simultaneous 
processing can be excluded. While consideradon of such policies is well within 
the scope of the current p^r, a lack of spax precludes a detailed discussion 
here. 

It is also worth noting that expecting a parly to indicate its intention to begin 
processing a personal data attribute (and possibly to be bloeked at that point 
by a privacy policy) need not be a fH*acticaJ major concern: It is possible to 
establish trusted third parties that store individuals' privacy policies and grant 
or deny semaphores based on the appropriate policy, (See the version of this 
paper published in the preproceedings for more informadon on the use of such 
semaphores in this context.) Again, availability and fault-tolerance issues for 
such third pardes will not be considered in the current paper. 

6. Conclusion 

This paper considered the possibility of representing personal privacy poli- 
cies using a process algebra. Simple examples were used to illustrate two 
major classes of privacy policies; aggregation policies and quantitative poli- 
cies. Automated analysis of the examples were used to identify the tradeoffs 
an individual has to make when enforcing such privacy policies. 

A number of open problems were introduced in the paper and will not be 
repeated here. One interesting implication of the approach has not yet been 
considered: If many individual privacy policies are modelled and publicly avail- 
able, a parly that processes private data can begin to measure the effects of its 
own processes in the light of known privacy constraints; it potentially becomes 
possible to measure how a certain acdon will constrain or enhance business 
processes. This, however, also needs to be left for future research. 
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Abstract In this paper we examine undesired inferences in distributed XML doc- 
uments. An undesired inference is a chain of reasoning that leads to 
protected data of an organization or an individual, using only intention- 
aJly disclosed information. We propose a framework, called Ontology 
guided XML Security Engine (Oxsegin), to detect and prevent undesired 
inference attacks, Oxsegin uses the Correlated Inference Algorithm to 
detect sensitive associations that may exist at a lower security levels. 
The system operates on the DTD's of XML documents to identify data 
associations and the corresponding security classifications. Oxsegin uses 
an ontological class-hierarchy to identify associations with two or more 
conflicting classifications, A Security Violation Pointer (SVP) is as- 
signed to a set of tags that contribute to the conflicting classification. 
The likelihood of a detected security violation is measured by a confi- 
dence level coefficient attached to the SVPs. 

Keywords: XML security, ontology based inference attack, data aggregation, cor- 
related data inference, multi-level XML security 



*Thi.i work was partially supported by ihe National Science Houndation under Grants llS- 
0237782 and DUE-Omm 





120 



DATA AND APPUCA TlONS SECURITY XVII 



1. INTRODUCTION 

Information systems have become a fundamental part of our everyday 
life. During the Iasi few years the number of distributed applications 
using extensible Markup Language (XML) increased and Ihe eonecpl of 
Semantic Web emerged [15]. XML query languages [1. 17], supported by 
ontologies [11. 9. 8, 16. 2], enable semantic-based information processing 
without human assistance. 

Unfortunately, techniques that support interoperation may also lead 
to unintended data disclosures. While individual data units arc usually 
carefully analyzed not to disclose any confidential information, corre- 
lated data may allow uniniended disclosure of confidential information. 
Current research in XML security follows two main trends: (i) Document 
Instance Security for digital signatures [5] and encryption [18] and (ii) 
Access Control Models for multi-level XML documents [3. 10. 4. 6, 14]. 
These techniques, however, do not consider the security implications of 
automated correlation of large amount of machine-understandable data 
that may lead to undesired inferences. 

Intuitively, an undesired inference occurs when a user is able to infer 
non-permitted information from inteniionally disclosed data and avail- 
able metadata, such as ontologies. This inference threat is similar to 
the inference problem in traditional databases, where the ontology cor- 
responds to the external domain knowledge. However, traditional in- 
ference control techniques are insufficient to provide protection against 
undesired inferences due to (i) the dynamic nature of Ihe Web, (ii) the 
large amount of information to be processed, and (iii) the fact that the 
owner of the sensitive information docs not have control over all publicly 
available data that may lead to undesired inferences. Up to dace, small- 
scale data availability and ihc lack of automated data correlation tools 
limited the threat of unwanted inferences via external domain knowl- 
edge. The impact of automated XML document correlations from large 
distributed databases using ontologies has not been yet fully addressed 
from the information security point of view. 

Our research targets the security impact of the ontology enhanced 
XML processing tools over large, distributed XML databases. We show 
that it is possible to use ontologies to mount specific data inference 
attacks on XML data. We develop techniques to detect and prevent 
attacks due to coexistence of sensitive association at a lower security 
level. To prevent these attacks, we propose the Ontology guided XML 
Security Engine (Oxsegin), Oxsegin is a probabilistic engine that com- 
putes security violation pointers over those tags that lead to low-level 
duplicates of sensitive associations. 
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The rest of the paper is organized as follows: Section 2 presents an 
example of ontology-guided attack using public domain data. Section 
3 describes the architecture and functionality of Oxsegin. Section 4 
gives the technical details for the correlated data inference process in 
the security engine. Finally we conclude and propose future research in 
Section 5. 

2. ONTOLOGY-BASED ATTACKS IN XML 
DATABASES 

Undesired inferences in multilevel secure dat^ases have been studied 
extensively (see |12] for an overview). The inference problem is to detect 
and remove inference channels that lead to disclosure of unauthorized 
data by combining authorized data and metadata. In Web environment, 
where correlated data may c*ome from several, independent sources, only 
a small portion of publicly avaiM>le data is under the control of the 
owner of the sensitive information. This work focuses on detecting repli- 
cated data associations with different security requirements. 

We assume that organizational data repositories contain both pub- 
lic (e.g., avail^le from the Web) *md confidential (e,g., available only 
to some of the users) data . To prevent undesired data disclosure, it 
is required that the security consequences of the release of new public 
data are evaluated before the release. That is, to determine whether 
unauthorized users will be able to combine the new information with 
other publicly available data to gain act'ess to confidential ihita. Ontolo- 
gies support semandc-based data integration, thus extend upon purely 
syntax-based data integration. 

To illustrate a possible inference attack, consider the document frag- 
ment (Table l.a) part of a database carrying information for upcom- 
ing air-shows. This document pn>vides information such as the address 
and driving directions to military hucses (Base_X) where an air-show is 
held. The second d(x:ument fragment (Table l.b), extracted from a local 
State Division for Health Administration, shows a map of drinking wa- 
ter basins within a given state. Finally, the third fragment (Table l.c), 
is part of a sensitive d(x:ument. containing data about the locations 
of the water sourc*es for sevemJ military bases, including Base_X. The 
security requirement of the military is that the information about the 
water reservoirs of military bases should only be accessible by autho- 
rized users. The air-show information (fragment 1) is available on-line 
and the drinking water basins information (fragment 2) is outside of the 
military protection domain and publicly available. Indeed, our example 
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is based on data available on existing Web site but we replaced the real 
data with fictional values. 



a. Air-show information 


b. Drinklo]? water basins 


c. Critical Infrastructure 


< Vxml version =" 1 , 0 " '> 


<?xcnl v«8jon=’*1.0”?> 


<?xml vefsion="l CT?> 


<shwi> , . P 


<waterMap> ,,. P 


<infraiftructuie> ... S 


< 6 ort>Base_X 


<districl>Di 8 trict_Y 


<base>Dase-X 


</fort> ... P 


</dislrict> ... P 


</base> ... S 


<address>District_Y 


< basin> Bas) n 


<water$ource>basin_Z 


</address> ... P 


</baem> P 


</ water Souxce> ... S 


</show> 


1 </watermat» 


< / infraatructure> 



7 hbU i. Uodesired Inference from Public Data 



A possible ontology for this attack unifies the <waterSource> with 
<basin>, <fort> with <base> and <address> with <district> tags. 
Using this correlation, the attackers gain access to secret information 
(association between the Base_X and its water source in Basin_Z), with- 
out any access to the critical infrastructure database. Note, that the 
complexity of this attack is reduced by the simplicity of the ontology 
and the uniform access to online resources, 

3. ONTOLCKJY GUIDED XML SECURITY 
ENGINE 

The motivation for the design of Oxsegin was to assist security offi- 
cers and database administrators to securely update XML databases by 
identifying possible security violations from illegal inferences. Oxsegin 
uses a probabilistic inference engine with varying precision levels. Ox.se- 
gin indicates the possibility of unwanted inferences where the correlated 
data from the test files (publicly available data) matches the reference 
file (protected, confidential data). If unwanted inference is detected ap- 
propriate countermeasures must be performed, e.g.. withhold some of 
the test files or execute non-IT measures. 

The security engine has four main components: the Probabilistic In- 
ference Module - PIM. the User Defined Inference Parameters Module 
- UDIPM. the Ontology Module and the XML Database Access Mod- 
ule. The Input and Feedback Module - IFM is not incorporated in the 
Oxsegin architecture. The IP^ functionality is to supply the reference 
and test XML set. the inference parameters and to decide the appropri- 
ate actions if a security violation is detected. The response policy on 
detected security violations is outside of the scope of this paper. 

PIM computes possible security violation pointers between the ref- 
erence document and the set of test documents. Intuitively, a security 
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violation pointer indicates lags from the corresponding reference and test 
DTD files that might constitute unwanted inferences. For each security 
violation pointer. PIM computes an associated confidence level coeffi- 
cient that reflects the likelihood of security violation involving the set 
of lags. UDIPM allows the security officer to define different inference 
processing parameters that will control the complexity of inference anal- 
ysis. The inference uses the semantic formalism and concept hierarchy 
supplied by the Ontology module. 




Figure I. ReplicaiecI Inform^lion under Differenl Classification 



The XML Database Access module represents a gateway to a collec- 
tion of XML documents. The XML database can be the local, public 
document repository or files accessed via HTTP within a given web do- 
main. As a result. Oxsegin can be used to securely publish documents 
over the web. In this case the reference DTD is the protected document 
and the test DTD is the set of all documents from the public domain. 

3.1. Probabilistic Inference 

PIM uses a set of procedures to identify security violations employing 
the ontology module to guide the inference process, Secdon 4 describes 
in full details the Correlated Inference Algorithm. The The input from 
the ontology module is used to abstract the concepts represented by the 
lags within the DTD files, A security violation pointer SVP is assigned 
to every unwanted inference. The confidence level coefficient CLC is 
computed for each SVP. based on the weights of the concepts in the 
ontology, the relative position of the lags in the DTD flies, and the 
rcladve position of the concepts in the ontology class hierarchy. 
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Definition 1 (Securiry Violation Pointer) Security Violation Pointer 
{SVP) is a set of tags T ^ {ti, tpj] that represent a possible securiry 
violation via unwanted inference. 

Definition 2 (Confidence Level Coefficient) The Confidence Level Co- 
efficient (CLC) of an SVP is the likelihood of the inference involving the 
tags of the SVP. 

Within a DTD, we distinguish between synlaclically identical lags at 
structurally different locations. We define all lags as a pairs, containing 
the tag's name and the tag’s path information from Ihe root node of the 
DTD. For clarily, in I he following we omit Ihe path information unless 
il is needed lo diffcrenliale between the lags. 

To formalize ontologies we adapt the use of Frame Logic [13] as Ihe 
conceptual modeling language. We assume that the security officer as- 
signs a weight to each concept in the ontology class hierarchy to differ- 
entiate between less and more specific concepts from Ihe perspective of 
the protected sensidve information. The more specific a concept is, the 
larger Ihe weight assigned to il. The root of the ontology class-hierarchy 
has a minimal weight since it is the least specific concept. Concepts 
lhal are relevant lo Ihe given knowledge domain and the specific secu- 
rity requirements usually carry larger weights. After Ihe security officer 
assigns Ihe weights for each concept, the system computes the normal- 
ized weights for each concept. Normalized weights reflect Ihe likelihood 
of the same syntactic forms to represent Ihe same semantic concepts. 

Definition 3 (Ontological Ah.siraction Level) Given the concept Cfrom 
ontology 0. the Ontological Abstraction Level of C. denoted as OAL(C), 
is n if C is located at depth n w the corre.sponding ontology class hier- 
archy. The root concept Cr of the class-hierarchy has OAL(Cr)^0. 

DeHnition 4 (Base Ontological Abstraction Level) The Base Ontologi- 
cal Abstraction Level of a tag t, denoted as BOAL(l), is the OAL of the 
concept C contained within the tag t. 

Definition 5 (Abstracting a concept N steps) A concept Cfrom an on- 
tology 0 is abstracted N steps when it is replaced N times by its imme- 
diate parents in the corresponding ontology class-hierarchy. 

Definition 6 (Container and Data Tags) A container tag is an XML 
tag that holds only structural information in the form of other XML tags 
and has no tag attributes. A data tags is an XML tag that contains at 
least one unit of information. A data tag may contain data and container 
tags. 




Correlated Data Inference 



125 



4. CORRELATED INFERENCE 

In this section wc propose an inference procedure that detects undc- 
sired inference attacks within a particular knowledge or semantic do- 
main. The Conelated Inference Algorithm detects ontology-based at- 
tacks similar to the one described in Section 2. The procedure checks 
a reference DTD structure (corresponding to the classified information) 
against a set of test DTD structures (corresponding to the publicly avail- 
able information) by abstracting tags using the ontology. 

The main data structure used by the Correlated Inference Algorithm 
is an Inference Association Graph (lAG). Intuitively, lAG represents the 
associations among tags of an XML DTD structure. The nodes of an 
lAG correspond to the XML data tags and the edges represent associ- 
ations between the tags. Figure 2 represents the lAG corresponding to 
the XML files in Table 1, 




lest set lAGs reference lAG 



Figure 2. Inference As5^isiion Graphs lAGs 

Each association has an attached Association Probability Coefficient 
(APC) that reflects the likelihood the corresponding nodes represent 
related concepts. In addition, associations can be classified according 
to the security policy of the organization. A security violation pointer 
identifies associations of different lAGs where two or more associations 
exist among the same tags but they have different security classifications. 
Such associations represent cases where users can derive information 
in one set of documents while they are disallowed to axess the same 
information in a different set of documents. 

Dennition 7 (XML As.wciation) For any nvo nodes m ond riQ in the 
DTD and their immediate parent P with security label Lp , P defines an 
XML association between ni and r \2 ■ The association has a correspond- 
ing security label Lp and P represents ike association source. 

Definitjon 8 (Association Prohahility Coefficient) Association Proba- 
bility Coefficient, denoted as APC. corresponding to an association be- 
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iween lags nj and U 2 with an association source P. represents the proh- 
ability ihai P is used lo setnaniicaliy correlate lags nj and 

Definition 9 (Inference Association Graph) The Inference Association 
Graph of an XML DTD structure, denoted by IAG-(V. E). is a graph 
with nodes V (data lags of the XML) and edges E (associations among 
the tags). Each edge is labeled with a pair (l,p, APCp), representing the 
security label and probability coefficient of the association source tag. 

Definition 10 (Document Structure Level DSL(t)) Given a tag Tfrom 
a DTD tree D, the document structure level of T in D. denoted as 
DSL[T), is the ma.ximum depth of the suh-tree rooted at T All the leaves 

h) hy -y k DSL(k) = 0. 

Algorithm 1: Build lAG 
Input: DTD 
Output: lAG 
BEGIN 

POR ALL dat& tags Tt in DTD DO 
Create a corresponding node Vt 
FOR ALL tags T. in DTD DO 

FOR ALL Vf, Vj, such that T« is the nearest parent of both tags 
Tp, T*, corresponding lo nodes V, and V*. respectively AND 
Depth (Tj)- Dept (T()<MaxDepth. D€ptii(TA)'Dept(T«)<MaxDepth DO 
Create the edge e between (V^, V«b) 

Label e with (Lr, » APCijk) 

END 

Note, that it is always possible to find an XML association between 
any two tags in a DTD structure since the root tag is the parent for ail 
tags in the DTD tree. However, this type of remote association is rarely 
relevant. In general, it is reasonable to assume that APCs decrease with 
the distance between the associated elements and the source. Algorithm 
1, gives the procedure to build the lAG. To reduce the complexity of 
the inference process, the algorithm limits the number of tags considered 
for XML associations. Associations arc considered only if the relative 
difference between the tags and the association source in the DTD tree is 
less than Max Depth (set accordingly to the specifics of the XML data). 

“ 1 + Depth(T,)-~Depih(f,) * 1 + Depth(Tk) - Depth(T^ ' 

1 1 1 

1 + \Depth(Tj) - Depth(T^)\ " DSL{T^) + 1 ‘ D5L(T*) + 1 
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l+Cq<l.m)-OwVr.) l+P«t<i(n)-C.-ptJ.{r.) coefficients in the defi- 
nilionof APC^yk quantify the relative depth difference in the DTD tree 
between the associated tags and the source of the association. A PC de- 
creases with the distance between the tags and the association source. 
i + 1 bepth (t ! - J>eyiK(rjt ) | c^®ff*cicnt quantifies the relative depth difference 
between Ac associated tags. Tags at the same depth have a conespond- 
ing APC larger than tags at different depth in the DTD tree. 
and coefficients quantify the structural complexity of the as- 

sociated tags. Tags that represent the root of larger sub- trees are more 
likely to be container tags, and this reduces the relevance of any associ- 
ation involving them. 



Object []. 


OALsO WGT*1 


P*l/50 


w&tec$aurce :: Object 


OAL=l WGT=15 


P=15/50 


basin waterSourcc 


OAL»2 WGT^l 


P=l/50 


ploce Object 


OAL=l WGT=18 


P= 15/50 


district :: place 


OAL*2 WGT*1 


P*l/50 


address 't place 


OAL*2 WGTal 


P=l/50 


base Object 


OAL*l WGT=15 


P=^15/50 


fort t: base 


OALa2 WGTal 


P=l/50 



S. Onti^gy repretteated with Fiaoie Lo^ statements 



After building the lAG for each XML DTD structure in the test set, 
the ontology is used to integrate them into a single structure - the test 
set lAG, Tlie Frame Logic statements in Table 2. represent the ontology 
associated with the knowledge domain of the XML DTD structure in Ta- 
ble 1. Each concept is shown with the associated ontology abstraction 
level OAL, weight WGT, and normalized weight P. If the DTD struc- 
tures in the test set belong to the same knowledge domain, abstracting 
the tag names may create pairs of duplicated nodes among different 
lAGs. Merging the duplicated nodes connects the test set lAGs. Each 
node in the I AG has an attached Concept Abstraction Level coefficient 
(CAL). Intuitively, CAL reflects the likelihood that the new concept is 
an abstract representation of the tag that is replaced. For the initial con- 
cepts in the DTD structure, CAL=1. Then for each abstraction, CAL 
is modified using the probability of the new concept in the ontology. 

Defi n I Hon 11 (Concept Abstraction Level) Concept abstraction level 
(CAL) is the likelihood that the concept from the ontology hierarchy is 
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an ah^lraci representation of the initial XML ta^ name. For repeated 
replacements. CAL is the prohahiliry the present concept is an abstract 
representation of the original tag name. 

Given Ihc tree structure of Ihc XML documents as well as the on- 
tology hierarchy, ail tags would eventually collapse into a single node if 
abstracted to the root of the ontology. To prevent this from happen- 
ing. the Correlated Inference Algorithm has a set of restrictions on the 
abstraction process and the tags that it uses. The concepts arc only 
abstracted within two predefined OAL limits: MaxOAL and MinOAL, 
MaxOAL is usually set to the depth of the ontology hierarchy tree while 
the MinOAL is set according to the specifics of the ontology. Usually. 
MinOAL is the average ontology depth of the concepts targeted by the 
inference attacks and is set by the security officer based on a particular 
knowledge domain. The second restriction on the abstraction process is 
based on the targeted tags. Tags located towards the root of the XML 
document arc usually container tags, mostly used for structuring the 
document and rarely involved in semantic correlations. The security of- 
ficer assigns a maximum level MaxDSL in the XML structure to consider 
tags in the abstraction process (DSL the document structure level). 

Integrating the test set lAGs simulate the natural human brain infer- 
ence process in three distinct stages. In the first stage the concepts as- 
sociated with XML tags arc abstracted, unifying same notions originally 
under different syntactic forms. In the second stage, by eliminating the 
duplicated nodes and collapsing the multi -structure lAGs, the system 
simulates the inference link between multiple files with related data. In 
the third stage the system performs a transitive correlation to simulate 
linking XML tags through similar abstract concepts. The transitive cor- 
relation relates two tags through an XML association (I AG edge) with 
a common third tag. Since the targeted inference is usually between 
multiple DTD structures, it follows naturally to perform the transitive 
correlation after duplicated node reduction. Algorithm 2, gives the for- 
mal description of the Correlated Inference Algorithm, 

Each edge added in the transitive correlation of the test set I AG rep- 
resents a possible illegal inference. The Correlated Inference Algorithm 
checks all these edges against the reference lAG to identify security vi- 
olation pointers. The test for security vioiation pointers is performed 
on edges, since the edges represent valid XML associations. Each edge 
added to the test set I AG by the transitive correlation is compared to 
all edges in the reference I AG. The system places a security violation 
pointer (SVP) on pairs of edges between similar nodes if the reference 
edge security label dominates the test set edge security label. Intu- 
itively this means that an association from the reference DTD structure 
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Algorithm 2: CorreiAt«d Inference 
Input: Test eet lAGs and Kefercnce lAGe 
Output; Security Violation Pointers (SVP) 

MAIN 

Cheek security vic/otion for ail existing edges of test and reference lAOs 
FOR all edges use Procedure 2 to identify SVPb 
AhstTQct tags in test I AGs to create new associations 
Let S be the set of all tag pairs (Ti, T^)€ test set lAGs 
FOR ALL pairs (Ti, T,) in S 
Use Procedure 1 to abstract T{ and Tj to the oearest 
concept c such that c = 7^ ^7f 
IP7y«r/ THEN 

Merge nodes Ti and T, : 

Remove T>; direct all edges toTii CALT,«mjn(CALr,;CAirr^j 
Create edges fftroupft froruihve correlation: 

FOR ALL tags Ta and T* with an edge to Tt DO 
Let security label L»max[U(T.»i\>;Le'(T.,Tj,>) 

Let APC*APC«(t<,i\)*APC«*(t^^t^) 

Connect Tk and Ta ^ Sn with UImI (L»AFC) 

Check security vitiations due to newly created edges 
FOR all new edges use Procedure 2 to identify SVPs 
Check data-ievei matches of SVPs 
FOR V SVPi such that CLC,>DSTcoef DO 
Perform data search on associated tags 
IF data'level match found THEN 

CLC**l 

BND(MAIN) 

Procedure 1: Abstract tag T 
Input: Ontology class hierarchy H, tag T 
Output: (Abtracted T)b 7^ 

Let c, Cl , . . . , Cn concepts^ K, c » T, Ci immediate parent of Ct^i 
T°*T, n < MinOAL 
FOR i*i TO n DO 
T‘-ci 

CALr.*CALr».i*P(c< ) 

£ND(Procedure 1) 

Procedure 2: Edge test for SVP 

Input: edges c & {rvi.ns)* s' = (ni^n^) with security claeel heat ions L«, Iv 
Output: SVP and CLC or nothing 
Abstract tags of nodee m and nj of e and ni and of s' 

IF e s/t s' (n* — nj AND nj = nj') and Lt#L«', say L« yl^f THEN 
CAL«vf»iCALm«s»CALm»>i» (average, max, rain) CAL fors, s' nodes 
CLC*CAUvrj*APC**APC,/*{l-|CAL».<,.-CAL,«M|) 

Place SVP on e and s' nodes with CLC 
BND(Proeedure 2) 
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is classified at a higher security level than an association atnong the lest 
DTD structures discovered by the transitive correlation procedure. The 
edges are matched for a security violation employing again the ontol- 
ogy hierarchy to abstract concepts for each tested edge. Each SVP has 
a confidence level coefficient CLC computed based on the APC of the 
edge and the CAL of the nodes. The last coefficient in computing CLC. 
1 - \CALmo^ ~ CALmin\ quantifies the relative difference between the 
maximum and minimum level of abstraction for the concepts in the XML 
associations. Concepts on the same level of abstraction in the ontology 
hierarchy have a higher associated CLC. 

Figure 3 shows the reference lAG and the integrated test set lAG 
corresponding to the lAGs in Figure 2 and the XML files in Table 1. 
The tag <fort> was abstracted to <base> and the tag <basin> was 
abstracted to <waterSourcc>, Both tags <address> and <district> 
were abstracted to <base> inducing a transitive correlation between 
<base> and < water Source>. The new XML transitive association be- 
tween <base> and <waterSource> is classified public according to the 
Correlated Inference Algorithm, This triggers a security violation be- 
tween the test set and the reference lAG where the same association is 
classified secret. 




Figure 3, Unified Inference A&5^iaiion Graph 

If the CLC corresponding to a particular SVP is above the Data 
Search Threshold coefficient (DSTcoef), the system provides low-level 
data granularity search. If data items associated with the reference and 
test set XML DTD structures match, the associated CLC is set to 1. 
the maximum confidence level. The low-level data search provides max- 
imum security but also maximum processing complexity. High-level de- 
tection may produce false positive security violation pointers with high 
confidence coefficients. Data granularity search decreases the amount 
of false positives but does not guaranty to eliminate all of them. The 
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Correlated Inference Algorithm runs the analysis for security violation 
pointers on the DTD structure level. This represents an advantage for 
large XML documents databases where usually more than one docu- 
ment corresponds to any given DTD file. Operating at the DTD level is 
similar to high-level security detection with reasonable accuracy under 
reasonable computational complexity. For more accurate detection the 
procedure uses specialized data granularity search to identify security 
violations with maximum confidence level. 

5. CONCLUSION 

This paper presents a new method to prevent inference attacks in 
large XML databases. We show how ontologies can be used to imple- 
ment automated attacks on large XML databases and develop methods 
and techniques to detect such attacks. Although ontological inferences 
have been studied from the perspective of providing interoperation, the 
security impacts of these new technologies have not been investigated 
and there are no tools to prevent these threats. 

To the authors ’best knowledge, Oxsegin is the first proposal to pro- 
vide a semantically enhanced XML security framework. This paper adds 
a new component to the security engine to prevent inference attacks 
based on correlated data. The Correlated Inference Algorithm com- 
putes security violation pointers and their associated confidence level 
probability. The procedure can be tuned to run at different complexity 
levels to enhance the efficiency of the model. The main contribution of 
our model is to be able to handle large ajnount of semi- structured data 
that is infeasible by using human experts only. 
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Abstract A way lo prev eni, delay , I i m 1 1. or contai n the com promise of the protected data 
in a database is to encrypt the data and the database schema, and yet allow 
queries and transactions over the encrypted data. Clearly, there is a 
compromi.se between the degree of security provided by encryption and the 
efficient querying of the database. In this paper, we investigate the capabilities 
and limitations of encrypting the database in relational databases, and yet 
allowing, to the extent possible, efficient SOL querying of the encrypted 
database. 

We concentrate on integer-valued attributes, and investigate a family of open- 
form and closed-form homomorphism encryption/decryplion functions, the 
as.sociated query transformation problems, inference control issues, and how 
to handle overflow and precision errors. 

Key words: querying encrypted database, encryption algorithm, homomorphism 

encrypiion/decryptlon functions 



1. INTRODUCTION 

Mobile computing and powerful laptops allow databases with sensitive 
data to travel everywhere. Laptops can be physically retrieved by malicious 
users who can employ techniques that were not previously thought of, such 
as disk scans, compromising the data by bypassing the database 
management system software or database user authentication processes. Or, 
when databases are provided as a service [3, 4]. the service provider may not 
be trustworthy, and the data needs to be protected from the database service 
provider. These examples illustrate the need to 
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♦ Encrypt data in a database since compromise will occur with the 
traditional ways of securing databases such as access controls [17, 13], 
multilevel secure database architectures [5, 11, 7], database integrity 
lock architectures [7], or statistical database inference controls [1]. 

• Allow, as much as possible, standard DBMS functionality, such as 
querying and query optimization, over encrypted data. 

In this paper, we consider a database environment where (a) the database 
contains sensitive data available only to its legitimate users, and (b) the 
database can be captured by the adversary physically, and a compromise 
threat exists. We believe that a good way to prevent, delay, or contain the 
compromise of the protected data in a database is to encrypt the database, 
and yet allow queries over the encrypted data. This paper considers attribute 
(field)-level encryption for relational databases. We give an example, 
txamplc 1, Consider a relational employee database with the relation EMPLOYEE 
(Id. Salary) where Id and Salary are integer-valued employee id and employee 
salary attributes. Assume that f{) and g{). functions from integers to integers with 
inverses f and g* () respectively, are used to encrypt employee salaries and 
employee ids, and the relation EMPLOYEE and the attribute names Id and Salary 
are encrypted as the characters R, A. and B. Then the SQL query Q(DB) over the 
database DB (DB): 

SELECT EMPLOYEE.ld FROM EMPLOYEE 
WHERE Salaiy^a 

returns the employees with salary a. Q(DB) is rewritten into the SQL query 
QE(DBE)'3ver the encrypted database DB gas follows. 

QE(DBg): SELECT R.A FROM R WHERE B=f(a) 

Then, Qe(DBe) is submitted to the DBMS, to be executed against the database DBg< 
Assume that the output 0 (Qe(DBe)) of the query Qe(DBe) is a single tuple with 
value y. Then the value y is decrypted as g*^(y)» and returned as the output 0(DB) of 
the query Q(DB). 

We refer to the process of transforming the SQL query Q(DB) of the 
original database into the SQL query QE(r)BK) of the encrypted database as 
the query rewriting process. 

In this paper, we investigate techniques for encrypting a database, and 
the accompanying techniques to query the encrypted database, which we 
refer to as the antUiamper database, and explore the tradeoffs among (a) the 
security of the database, and (b) the query expressive power and query 
processing. The site (computer) in which the anti -tamper database resides is 
called as the amUiamper site. 
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Consider a database DB, and the set S of SQL queries Q on DB that 
correspond to the set of safe relational caleulus [16] queries'. Let DBe be the 
encrypted database DB (i.e,. f(x)=y, for all x 6 DB, ye DBe) with the 
transformed set Se of SQL queries Qg(DB6) on the database DBe. Por 
encrypting the database DB using the encryption function f(), we choose an 
encryption function f() that is a group fuynumorphism from DB onto DBg 
with respect to S [12]. i,e., for any query Q in S. we have Q(DB) = f 
'(QB(f(DB))). This means that (a) SQL queries in S can be completely 
evaluated solely using a single query Qg on the anti-tamper database DBg, 
and. (b) with the exception of decrypting the output ofQECDBg)) (possibly, at 
another "secure" site), there is no extra query processing burden on 
evaluating Qe(DBe). 

We make the following assumptions about the anti-tamper database: 

• The encrypting of the original database is transparent and unknown to 
the legitimate users of the database, (no extra query 
sped fication/tran.sformai ion burden on the legitimate users) 

• The general encryption mechanism is made available to the public, 
including the adversary. However, certain parameters of the encryption 
mechanism (e,g„ private keys) arc kept secret so as to make the 
protected information in the database secure, 

• The commercial DBMS that hosts the data docs not know that the data 
in its database is encrypted. Commercial DBMSs arc complex 
proprietary software systems, any security technique that is deployable 
without modifying the DBMS is more desirable over ones that require 
changes to the DBMS. 



2. COMPUTING ARCHITECTURE 

We employ the following computing architecture for our environment. 
Let the original datj^se DB be encrypted into the encrypted ianihtamper) 
database DBe. Now, if DBh directly becomes available to the adversary, its 
contents are devoid of semantics and, therefore not directly usable by the 
adversary. We employ an intermediary software agent, called the 
(Encryption/Decryption) which wc assume to be secure. That is, the 

adversary cannot capture the Agent software code, and reverse-engineer its 



Thus, a query Q in S his a Where clau.se with conjunctions and/or disjunctions of predicates 
p, and existential and universal quantifiers. The predicate p either (a) specifies that a 
variable does/d«)es not range over an attribute of a relation, or (b) .specifies “x0z" 'vherex 
is a variable, z l.s a variable or a constant, and 0 $ (<. >, . Q has a finite output 

and finite evaluation lime. 
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cncryption/dccryption algorithms. We consider two alternative architectures: 

♦ The agent resides at a site different than the site of the anti-tamper 
database DBei ^nd has significant computational power and storage 
space. We refer to this site as a secure site, and to the Agent as a secure^ 
site Ageni. There may also be a secure DBMS at the secure site. Wc 
refer to this DBMS as DBMSAjem. 

♦ The agent resides at the site of the anti -tamper database, and has little 
computational power. We refer to this Agent as the anihiamper-siie 
Agent. 

For both architectures, user queries are processed as follows: 

a. The user forms a query Q(DB) against the original database DB. and 
submits it to the Agent. 

b. The Agent rewrites the original query either 

i) A single query Qe(DBe) o'^cr the encrypted DB or 

ii) A set {QEi(DBE)|l<i<k} ofk different, k> 1, queries, 

and submits Qe(DBe) or query set {Qei(DBe)), respectively, to the 
DBMS of the anti -tamper database, referred to as DBMSe* 

c. The DBMSe processes the query Qe(DBe) or the query set {Qei(DBe)}, 
and returns the output 0 (Qe(DBe)) or the output set {0 (Qei(DBe))), 
respectively, to the Agent. 

d. In the case of a single output 0 (Qe{DBe)), the Agent decrypts 
0 (Qe(DBe)) into 0(Q(DB)), the legitimate output of the original query 
Q against the original database DB, and returns it to the user. In the 
case of the multiple output set {0 (Qbj(DBe))|» the Agent decrypts each 
output 0 (Qe(DBe)), performs, if necessary, additional computations 
with the decrypted output set to obtain and return the answer 0(Q(DB)) 
to the user. 

Note that the user site in this architecture can be the secure site, the anti- 
tamper site, or yet a third (secure) site. If the user site is the third site, we 
assume that there is a secure communication channel between the Agent site 
and the user site. If the user and the Agent arc both at the anti-tamper site 
then the decrypted output of a query returned to the user can be 
compromised (until it is destroyed by the user) if captured by the adversary. 



3. ORDER- AND DISTANCE-PRESERVING, OPEN- 
FORM ENCRYPTION 

In this paper, we concentrate only on the primitive data type integer. 
Next, we illustrate with examples the issues with the data type integer. 

Defn (Order-Pre.'ierving Encryption). Consider atlribute V of relation R, and the 
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enctyplion function f() for V values. The encryption function f() is order-preserving 
if when a > b for any two V values a and b in the original database DB then f(a) > 
f(b) in the anti-tamper database DBg. 

In other words, the encryption of attribute V retains the ordering in V, 
Arithmetic comparison operators <, >. >, and < (but, not = and 9I) of 
primitive data types (e.g.. integers) depend on the total ordering of attribute 
values. 

Integer attributes can also participate in arbitrary arithmetic expressions 
of SQL queries. Let us consider one of the simplest arithmetic expressions, 
namely, arithmetic difference, 

Defn (Difference-Preserving Encryption). Given an attribute V with nonnegative 
integer or real values, and an encryption function f(), f() is difference-pre serving if. 
for any two attribute V values a and b where (a - b) = k, we have f(a) - f(b) = r * k, 
where r is a constant. 

In general, an encryption function f(x) that is difference-preserving for 
integers (and reals) has to be affine, i.e.. f(x) = Ax+C, where C is a constant 
and A=r if x is a scalar. 

When wc employ an open-form encryption function, the system uses an 
encryption algorithm, which is more than computing a closed-form function, 
to encrypt original database DB into DBe* Since DBe creation is a one-time 
(datj^asc creation-time) task, employing a more time consuming encryption 
algorithm is acceptable. For decrypting query outputs as well as for 
intermediate processing, the agent also needs to execute a decryption 
algorithm. 

Consider an integer- valued attribute V with values X, to be encrypted 
using open form order-preserving encryption. Let us assume that the 
cncrypdon function f(X) and its inverse arc in the form of E(K.X) and 
D(K,Y). respectively, where K is the secret key. We would like to define a 
family of functions Y=E (K,X). X=D(K.Y), where X,Y. and K are 
non negative integers: 

1. K is the secret key. Given K. E and D should be efficiently computable. 

2. For all X, V, K, we have D (K. E (K.X))=X. 

3. It should be hard(see 3,2 Inference Control) to find X from Y or Y from X in the 

absence of knowledge of K, even assuming complete knowledge of the functions 

E and D, 

4. If X < X' then E (K,X) < E(K,X ) for any K. (Order-preservation) 

Assume that the domain for our function Ek, is the integers from I to N, 
and the range is the integers from I to M. For fixed K, let y„* EK(n) for | < n 
< N. Define a new sequence by 2(®yi - I. Zi4i®yB*i - Yn “ 1. In other 
words, the Zj's arc the differences (minus I) between successive values of the 
encryption function EK(fl). Then condition 4 above is equivalent to the 
statement > 0 for all n. 
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If we have any order-preserving function we can define the corresponding 
sequence z,,; and the converse is also true: given a sequence Z(, of 

nonnegative integers, there is a uniquely determined order- preserving 
function for which are the differences. Furthermore, we have the 
algorithms in figure 1 for computing the encryption function iis 

mverKDK(y„). 

Encryption; 

Ek( 1) :=1 2i; EK(n+l) := Ek(r) 1 +Zn.i; 

Decryption: 

Input: Y Output: Dk(Y) 
begin 

0; W Y; 

while W > 1 do begin i := i + J; W := W- z, 
endwhlle, 

if W = i then tecum Dk(Y) := i else output ’ Failure"; 
end. 

Figure t. Encryplion and decryplion algorilhnu for order*preseiving, inicgcr-lo-iniegercncryplion 
Our goal is to construct a family of functions indexed by a key K. which 
contains as little information as possible. One way to achieve this is to 
generate a pseudorandom sequence z, using an initial seed K, and then use 
the algorithms in figure 1 to define the encryption and decryption functions. 
There are a large number of well-known algorithms [8] for generating 
pseudorandom integers efficiently which have known security properties. 

To minimize information leakage of the proposed order-preserving 
encryption algorithm, one can optimize the encryption algorithm by altering 
the distribution of the 2%. For example, it might be belter if each Zi is 
uniformly chosen from an interval depending on the sum of the previous Zj. 
Figure 2 lists such an algorithm. 

1) Generate a sequence of random integers in the range (I, M). 

A&sumc that we have a family of pseudorandom functions R(K,n]‘^xn. where K 
is the secret key and Typically this generates a stream of random 

bits, which can then be used to produce random integers[9]. There are a large 
number of pseudorandom number generators with useful security properties. 
See. for example. M. Blum and S. Micali [2j for an early example, Here, (he 
key serves as the initiator of the sequence. 

2) Define Zt by the rules: 

fa)Si:*Zi:=yi; 

(b) for k> I, define A*,, as Ak«:M -S|.; 2 *.j *: Int [yi,.i*Ay/M); 

(c ) DeHne S|, as Zk«i 
The encryption function is then defined by ffk)®Sk, 

Figure 2. Encryption fimclion f() wilh uniformly distributed and expanding z,'s 
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3.1 A Class of Queries with Simple Query 

Transformation and Same-Cost Query Processing 

For the class of SQL queries equivalent to safe relational calculus 
queries, there is a very scraighlforward transformation from Q{DB) to 

Qe(DBo): 

Qucrj Trun.‘^orcnation Rule: Replace each constant c in Q(DB) with f(c) to 

obtain Qg(DBe). 

The query Q of example 1 illustrates the use of the Query Transformation 
Rule. 

Theorem 1 below slates that f() as defined in figure 2 is a group 
homomorphism from DB to DBg with respect to the set of SQL queries 
equivalent to safe relational calculus queries. Moreover, the cost of 
evaluating a transformed query over the encrypted database is the same as 
the cost of evaluating the original query over the original database. 

Theorem 1. Lei DB be a relational database, fO he an encryption function as 
defiaed in Figure 2, DBg be the eacrvpied database obtained from DB using f(). and 
0(Q(DB)) be the output of query Q on database DB. Then for any SQL query 
Q(DB) that is expressible ia safe relaLional calculus, the correspouding single SQL 
query Qg(DBg) obtained usiog the Query Transformation Rule is sucb ibat applying 
f^(y)to each encrypted value y inO(Qe(DBE)) produces 0(Q(DB», 

Proof: See the Technical Report flO], 

Remark I. Given any relational DBMS M, ibe query evaluation cost of Q(DB) on 
M ii equal to the query evaluation cost of Qe(DBe) on M. 

Proof. Follows from the inieger-to-inieger, order-preserving transformations of 
each attribute. 

Theorem 1 and Remark 1 are highly practical since (a) the class of safe 
relational calculus queries is a reasonably large class, (b) transformation 
from Q to Qg is straightforward and not cosdy, and (c) all things being equal 
between DB and 0Bg except encrypted values, processing Q and Qgiake the 
same amount of time. Nevertheless, Theorem 1 fails for SQL queries with 
arithmetic expressions and/or aggregate functions, as well as for SQL 
queries with objeci-relationaJ features such as derived or complex types (as 
opposed 10 primitive types integers, reals, and strings). We give an example. 
Example 2. Assume that the relation EMPLOYEE and the attribute name Salary ore 
encrypted as characters R and B, and the attribute Salary is encrypted using an 
order-preserving encryption function f(). Then, the SQL query 

SELECT AVG (EMPLOYEE.S alary) FROM EMPLOYEE WHERE Salary > 100.000 
will need the evaluation of two quenes; 

Qbi (DBg): SELECT SUM(R.B) FROM R WHERE B > 100.000), 

Q 62 (DBe): SELECT COUNT(R.B) FROM R WHERE B > 100,000) 
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And, the Agent will compute the answer as a function of the responses 0| and Ojto 
Qei» Qe^ respectively, and f(). The answer is given by f (O 1 /O 2 ). This formula 
works because the special form of f() preserves arithmetic means. 

We make three observations. First, the query rewriting approach of 
Example 2 will fail if f() is not additive, i.e„ f(a + b) = f(a) + f(b). That is, 
for any x and y values in ihe Salary allribute. the additivity property 
guarantees that f’* (f(x) + f(y)) * f ' (f(x + y)) ® (x + y). Second, open- form 
encryption functions by definition do not satisfy ihe additivity property. 
Third, when the aggregate operations are used in nested SQL queries (with 
correlated variables), the issue of rewriting the query becomes even more 
difficult 

Example 3. Consider the query in example 2. Now. assume that we have used an 
"instance-based” encryption; i.e., for each salary value a, there is a distinct f(a) 
value, not expressible in a closed form and maintained in a secondary data structure 
at the Agent. In this case, the query rewriting scenario of example 2 fails, and we are 
forced to return all of the salary values in the desired range as 

Qej (DBb): select R.B FROM R WHERE B > ft 100,000) 

with Ojus the output. Then the Agent will need to (i) decrypt and sum up all of the 
values in the output Oj into X. and (ii) compute the output of the query as X/O 2 . 
This scenario will incur heavy time delays since DBg salary values have to be 
shipped to the Agent, and the Agent needs to perform (possibly, a disk-based) 
addition, independent of the database query optimization process. 

Thus, one important goal in query rewriting is to have minimal 
performance degradation in transforming and evaluating ihc expecled sel of 
queries of the original database DB. 

3.2 Inference Control 

Lei V be an inicgcr-valued attribute and Domain of V, Dom(V) be a set 
of integers in (1. N], Let the encrypted domain E(Dom(V)) be a sel of 
integers between the range [1, M|. where M » N, Let Ihc allribute V values 
be represenled by v*, 1 £ n, which are encrypted toyj's with an encryption 
function f(V|). Vj, y^ arc monotonically increasing, that is v, < Vj when i< j. 
and yi < y|.We define the adversary’s Knowledge Space (KS) as the sel of 
two-tuples (Vi, yj) i.e., for (v„ y,) e KS, ihe adversary knows in advance that 
Yi - And. ihe adversary may or may nol know ihal v,’s range is [1, N|. 
and y,‘s range is [1, M). 

We now briefly investigate the compromise risk; i.e,. given KS. how 
much ihc adversary can infer about the values Vj, More precisely, when IKSI 
= k. we want lo know the probability that an unknown (V|, yi) pair is revealed 
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lo ihc adversary. The system is said to be compromised when (Vj, yj is 
revealed to Ihc adversary with a probability above the threshold x. 

Let denote a guess by the adversary for v,. Let P{Vpess“Vr| KS), (v,» 
y,) is not in KS, denote the probability that Ihe adversary learns f'(yr)“V^ 
given KS. Then, we select the system-defined parameters so that P(Vjju*y®v,) 
< t for all r. 

When the adversary (a) docs not know any v,, that is, KS = { }, and (b) 
knows that the domain range of V is (1, N], and Ihe encrypted domain range 
is [1, M| then Ihc probability that n unknown v, values are revealed from n 
distinct yf values is equivalent to the probability of guessing n numbers over 
the range [1, N], Choosing yi, the adversary guesses V| over [I, N] by Vg„e,j 
Then the possible range of Vj is [1, N-n+l| and P(v^itfjs*V|) * l/(N-n +1). 
Similarly, with KS = {(V|,yi)), the possible range for Vjis [V|+l, N*n+2] and 
P(Vgu«„=Vj I KS={(V|, yi)}) = l/(N-n-V|+2). Generalizing, we have 
P(Vg^»=Vk.i|KS=KV|,yi), (V 2 ,yj), .... (vi,y,)!)= l/(N-n-vg +k+l). Note that 
the uncertainty bound for each value depends on the previously 
compromised value and the next compromised value. Furthermore, if the 
adversary does not know Ihe size of Ihc encrypted domain M, (s)he can use 
the largest enerypled value as Ihc upper bound for M. Finally, the worst 
case is the case where Vj values in KS are evenly disiribulcd over the domain 
range. 

To distinguish the known values in KS from the original data instances 
of V, we denote KS = {(S|, l|). (sj, ta). .... (sg, tk)|, where t, (=yi) is the 
encrypted value of S; (* V|)» and S; < Sj when i < j. For any two consecutive 
elemcnls Sj and Sj^i of KS. we denote by S a sel ofvj values between Sj and 

and by T Ihc sel of encrypted y* values between tj and lj*|. Assuming Vj 
values in S arc equally likely (i.c,. uniformly disiribulcd) to be anywhere 
between S| and we can compute the compromise probability as follows. 
Let Vgi^gg denote the adversary’s guess for Vr®Sj+l in S, Then P(Vq«e*v,) = 1/ 
Sj.r Sj * tS|* That is, once the values Sj and Sj.j arc known by the adversary, 
the corresponding range between tj and tj+( is of no significance for the 
uncertainty range of Vr- Similarly, when v, = •! then P(Vg„p„gVr) = |/S) - 

(no. of encrypted values less than tj). And. when Vr * St +l then 
1/ N - Sii ^ (no. of encrypted values after W). Combining the three cases for 
ally, values, compromise occurs when max^ [P(Vgy«8*v,| KS)) > t. 

It is possible to have domain values with different distributions. Let R be 
a range between any two known values Sj, Sj.iin KS, and having fTl unknown 
values distributed over R with a hypergeometric distribution. Assume that 
the adversary guesses m values from R. If we let random variable X denote 
the number of correctly guessed values then A=k means Ihe adversary got 
exactly k values correct. So, Ihc probability of X=k would be: 




142 



DATA AND APPUCATIONS SECURITY XVII 



f|7lYW-|7’l\ 


M 


U A , 





P(X*k) 



By ihc definition of hypcrgeomctric distribution, E(X) = mITI/R gives the 
expected number of compromised values. 



4. ORDER-PRESERVING CLOSED-FORM 
ENCRYPTION AND DECRYPTION 

The advantage of closed-form decryption is speed, whereas open-form 
decryption may be costly-even when the decryption requests are sorted and 
batched. On the minus side, inferring the closed-form of the decryption 
function for an attribute amounts to compromising all values of the attribute 
unless one-way encryption functions arc used to protect the key K, 

Closed-form encryption for integer- valued attributes has the 
disadvantage that, because a single closed-form function is employed for 
encryption, controlling the magnitude of the encrypted values becomes 
difficult, leading to overflow problems. One can employ a variety of 
techniques to control the sizes of encrypted values; here we discuss one 
approach: encrypting a single integer value into a set of integers. 

We would like to find encryption functions whose closed-form inverses 
exist, are cheap to compute, and “lossless". We say that an encryption 
algorithm E is lossless for an attribute V when there exists a decryption 
algorithm D such that, for any value x . l£ X S N, D(E(x)) * x. 

When the attribute value x is encrypted using a function, say, E(x) * 
CiX+ Co, we refer to the constants Cq and C( as the key K. We assume that 
users are informed of the encryption function, but not the key. We call the 
number of such constants Cj as the degree of security. Our goal in this 
section is to come up with an encryption algorithm E such that, given the 
desired degree of security n, the algorithm E locates a "lossless" encryption 
function E() with the degree of security ofn. 

4.1 Single Encryption Function and its Inverse for 
Decryption 

One encryption approach is to use a single polynomial function f(x) as 
the encryption function E. Obviously, in this case, the degree of security is 
the number of constants employed by the function f(x). Therefore, given n as 
the degree of security, the goal is to find an n degree polynomial that has an 
inverse function inclosed form: 

F(x) = C„X" -*• + ... + C|X + Co 
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Remark 2. Lei f be a continuous function on the closed interval [X|, Xj] as^sume 
that f is slrictiy increa.sing. Let f(X|) — yi and f(x 2 ) ® yj- Then the inverse function is 
defined on the closed interval [yi, yj]. 

Thus, to check whether the funelion has the inverse function or not, we 
can compute dev(f(x)) = 0. If there exists at most one solution for dcv(f(x)) 
= 0 . then the inverse funelion of the polynomial exists for all x. If there 
exists more than one solution, we find the largest k such that dev(f(k)) = 0; 
and the inverse function exists for x S k (by Remark 2). The problem with 
this approach is that in general, the closed form of the inverse function of an 
arbitrary polynomial function may not exist even if the inverse itself exists. 
Therefore, next we introduce the approach of multiple encryption functions. 

4.2 Multiple Encryption Functions and an Inverse 

Instead of finding the inverse of a single n degree polynomial for a 
requested n degree of security, we now apply n 'simple' functions iteratively 
where each function has its closed form inverse. Some examples of simple 
polynomials with well-defined inverse functions are listed below. 

f,(x> = CoX + C| f,(x) = C,x’ + Cj f,(x) = C,x’ + C, 

Given n as the desired level of security, our goal is to find a sequence of 
functions f, 1 5 i S k, from the above list as a sequence of encryption 
functions with, altogether, n constants Cj (as the key K) so that applying the 
inverses of each function in the sequence in reverse order constitutes the 
decryption. The encryption algorithm is applied as the sequence fj of 
functions in such a way that the output of f(x) becomes the input of fj4i(x) 
for Isi £ k-l. 

Example 4. Let fi(x) * C»X + Ct f 2 (x) * Cj + Cj, fj(x) » Cj X^+ C? 

E<x) - f, (f: (f,(x) ) ) - C, (C, (Co X + C, )' + C, + C, 

Note that each function fj is monotone; that is, for X\ > Xj» ffX|) > f(X 2 ). 

4.3 Nonlossy multiple encryption functions 

There arc two types of errors that may occur and may make the 
encryption lossy when applying a sequence fi, 1 S i S k» of functions as 
encryption/dccryption functions, namely, overflow errors (integers) and 
precision (round-off) errors (reals)[6]. 

When multiple functions are applied iteratively to encrypt attribute 
values of integer domain, the magnitude of the encrypted value rapidly 
increases even when we restrict the degree of each polynomial to either 1 or 
2. Since computer arithmetic uses limited (e.g. 32-bit or 64-bit) number of 
bits to store a number, an attempt to store an integer of large magnitude 




144 



DATA ANDAPPUCATIONS SECURITY XVII 



greater than 2^^ - 1 for 32-bil arithmetic and greater than 2^^ - 1 for 64*bit 
will produce an integer overflow [15], 

Therefore, to reduce the magnitude of encrypted values, one may apply 
the log function fio*(x) * logjx + C where C is a security constant. In this 
section, we investigate the use of the log function during encryption. Note 
lhal the log function’s input and output need lo be real values. 

Assume that the floating-point rcpresenlation has a base B and a 
precision p (i.e„ the number of bits to keep the fractional part of a real 
number). ± bo . b( bjb? ,,bp.i " B' represents the number ± ( bo + b| B ‘ 
bp., B-*'-" )B' , ( 0 £ bj < B ), where b| is called the significant bits and has p 
digits, and e is the exponent [9|. With B = 2, 24 bits are used for significant 
bits for 32 bit arithmetic, 53 bits arc used for 64-bit arithmetic [15]. 

When the encryption computations convert the domain of an attribute 
from integer to real (e.g., in the ease of applying fig|(x) * logj x ) or even 
when the domain of an attribute is real, information loss occurs if significant 
bits overflow (i.e., the precision error or round-off error occurs). 

When the log function is applied in the encryption function 

sequence, in order to avoid precision errors, we define the precision range 
for X with fl[x) * loga x by locating when f(x) loses its precision, i.e., we find 
X and x+1 where y„« log(x) . y^n * log(x +1)and y,»* 



Table !. Precision Limits oflagiCx) for 32-bit and 64-bn number representations 





32 Bn 


64 Bit 


X 

Log(x) = Log<x-*'l) 


757283 10 

757284.0 

19.530474.0 


2.02967093951847 • I0'*,o 

3.02967093951848 • )0’‘,o 
47.528239,0 



From Table 1, after the application of |og 2 (x) where x is a 32-bit or 64-bit 
number, the maximum value of lnt(logj(x)) avoiding precision errors is 19 
or 47, respectively. To avoid an early overflow error for attributes with large 
domain values, the function f^j^ ( )is always applied first. 

We propose the following techniques to control and avoid overflow and 
precision errors during the encryption process. (Sec (11) for the detail.) 

- After the application of each log function. We maintain an '‘encrypted- 
value vector” Vg such that we 1 ) store C • Fract(fj io^( )) - e, into the 
encrypted-value vector Vg,, (2) provide W\ - (Ini (f.iog ( ) ) + C’) as an 
input to ihe function f j ( ), where Int(r) and Fract(r) denote functions 
lhal relurn the integer part of r, and the fractional 24 bits of r as an 
integer, respectively, and C, C’ are constants, and (3)rcpeat steps (1) and 
(2) above after application of each fyo^). 
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- After applying fj.i (fi .2 (x)X let Z| * fi. 1.2 (fv3,i (x)) for Z\ < 2^' for 32-bil 
arithmetic. Before converting Z\ into a real number in order to apply the 
log function fj^i^ we split 32-bit integer Zi into Lcftj which indicates the 
leftmost 19 bits of 32 bit integer 2 ^ and Righti which indicates the 
rightmost 13 bits of z*. Then a different function sequence is applied to 
each part separately. 

Finally, we propose an encryption function sequence E(x) * f fk.i.jC 

fk-s,i( ••.( r),k>j( £s,j( fj,l( k\ 0 t{ Uji fj.i( fi.ioi (x))))))))-.))). *hcrc subscripts 
are used to number the functions and the function type (linear, quadratic or 
log). The subscript k of the function fk () in E(x) uniquely specifies the 
encryption function sequence. We refer to the subscript value k as the index 
of the encryption function sequence E. 

4.4 (venerating and Encryption Function Sequence with 
Desired Degree of Security 

By applying the results of the previous section, the relationship between 
the encryption function sequence index k and the desired degree of security 
d can be defined as 

d » a • ( (V3) • 7) + b 

where a is 0 if k < 3 and a=l if k > 3; and b is 0. 4, or 6 if (k mod 3) is 0. 1, 
or 2. respectively. Therefore, given the desired degree of security by the 
user, the system can generate the corresponding encryption function 
sequence E(x) in a straightforward manner. 

Thus, we have proposed an encryption function sequence E(x) as an 
alternative closed form encryption function. The degree of security of E(x) is 
the number of constants Cj (coefficients) employed by the function 
sequence, and the set of Cj in E(x) constitute the secret key K in the 
encryption. 



5. CONCLUSIONS 

In this paper, we have proposed the first steps of an approach to securing 
databases: encrypt the database, and yet allow query processing over the 
encrypted database. 

Much work remains to be done. Our approach needs to be extended to 
handle SQL queries with arithmetic expressions and aggregate functions as 
well as complex SQL queries with nested subqueries[14]. We have 
discussed only the encryption of integer-valued attributes; encrypting and 
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querying allribules of other primili ve/complex data types is another research 
direction. 
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Ahslracl The SDSD-.'iysiem offers siiaie-dependeni acce&s control in dii^iribuied objecl sys> 
teens. The system enforces protocols which declare sets ofacliviiy sequences as 
allowed, (hereby forbidding any occurence of an aclivity outside the context of 
an allowed sequence. In this paper we conceptually extend the SDSD*sysiem 
by introducing discretionary administration righu for controlling the activities 
of declaring, binding and starting SDSD-protocols. Additionally, we introduce 
second level administration rights for controlling the grant and revoke activi- 
ties concerning administration rights. Exploiting the powerful potentials of the 
SDSD'Sy.stem, the new concepts are implemented by special administration pro- 
tocols. Administration protocols are enforced with the same techniques already 
used for application protocols concerning the functionality of the underlying ob> 
ject system. In this environment recursive revocation is shown to be feasible. 



Keywords: Security, distributed object system, administration of access rights, access con- 
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1. Introduction 

Access control is a fundamental mechanism for enforcing security require- 
menls in computing systems. Conceptually, and highly simplified, access con- 
irol comprises two phases. In the first phase, one or several security administra- 
tors are declaring access rights, each of which slate that some user is allowed to 
perform some action on some object. In the second phase, each user request is 
intercepted by a monitor that decides on the basis of the declared access rights 
whether or not the request actually shall be executed. In implementations, usu- 
ally these phases are interwoven, and participants of the computing system can 
act both as administrator and as user. The basic approach of access control has 
been refined in various ways in order to deal with more specific aspects . In this 
paper wc deal with the following aspects: state-dependent access rights, mon- 
itoring for distributed systems, and constraining the administration of access 
rights by access control in turn. 

Concerning the first two aspects, we rely on our previous work (1, 5, 2] about 
the design of state-dependent access control and its enforcement in distributed 
object systems and the corresponding implementation by the SDSD-system (for 
5tate -Dependent Security Decisions). Varying the basic approach, access rights 
are no longer statically granted until an explicit revocation. Rather, in a con- 
ceptually first phase an administrator declares so-called protocols in order to 
specify which kinds of activity sequences of the distributed object system ate 
considered to be allowed for formal participants. After instantiating a protocol 
by binding actual participants to the formal participants and starting a concrete 
instance of such an activity sequence, the distributed monitoring system assigns 
and withdraws dynamic access rights on a short term basis for just a single ac- 
tivity, thereby enforcing that only allowed sequences can actually occur. 

R>r example, an administrator for an insurance company can allow activ- 
ity sequences of the following form (which informally circumscribes a formal 
protocol presented in Figure 2 of (2|): each such sequence starts by drafting 
a contract, followed by a careful inspection with an acceptance decision; de- 
pendent on this decision; either the contract is confirmed and subsequently 
cither it becomes valid based on a timely payment or it is rejected based on 
a missed payment deadline; or the contract is immediately rejected. While 
enforcing state-dependent access control, for instance the activity '‘contract re- 
jection'* cannot occur as an isolated event, rather it is dynamically enabled only 
just after the pertinent event of “missed deadline" or “negative inspection", 
respectively, and after an actual execution, the activity “contract rejection” is 
immediately blocked again. 

The present paper aims at extending the SDSD-syslcm with respect to the 
third aspect mentioned above, namely, how in turn to control the administration 
of allowed activity sequences. More specifically, we first address the most 




AdminUtraiion Righis in ihe SDSD~S\'stem 



151 



argent problem: How to alUnv parttcipant.s of Ihe sy.slem lo act as aJmtnistralor 
who can declare protwols, hind actual poriiciponts to an instantiated proUKol 
and Stan a concrete activity sequence? We even go one level funher and 
address the immediate follow-up problem: How to allow participants to allow 
other participants to act as administrator? Additionally, we also consider 
Ihe revocation problem for both levels: How to revoke allowances to act as 
administrator or to ytrant such allowances, respectively? 

In terms of our example, we deal with the problem how one or more “ad- 
ministrators" are dynamically introduced and controlled, and how a protocol of 
the sketched kind is coming into existence and exploited in a controlled fash- 
ion. Abstractly speaking, we investigate the problem of administration rights 
within the framework of state-dependent access control in distributed object 
systems. This problem has been studied before within different frameworks, 
including theoretical studies on deciding the possibility of the proliferation of 
a right (showing undecidabiliiy in general [8] and decidability of special cases 
like the take-grant model ( 10]), mechanisms for dynamic rights amplification in 
systems like UNIX (by the su id-flag) (6) or Hydra [17], a variety of revocation 
options as in Oracle [11, 12] or role-based administration of roles [16. 4], 

Though our solutions are original for our framework, as discus.sed in detail in 
Section 6, they are based on an established paradigm, namely, to smoothly inte- 
grate the control of the administration with the control of the primary function- 
ality, Furthermore, we follow the well-known paradigm of discretionary access 
control. More specifically, the contributions of this paper can be summarized 
as follows: ( 1 ) By re-examining our SDSD-system, we identify fundamental 
administration tasks, namely protocol declaration, protocol (instance) binding. 
and protocol (instance) staning (Section 2). (2) Ba.sed on the literature, we set 
up a conceptual design with discretionary administration rights as first level 
rights for the fundamental administration tasks and corresponding second level 
rights for controlling those of the first level. This design also includes the no- 
tion of ownership and control of revocations (Section 3). (3) Exploiting the 
powerful potentials of the SDSD-system. we implement the design by defin- 
ing appropriate administration protocols for the SDSD-system. which are then 
shown to enforce the conceptual administration rights by the (slightly extended) 
mechanisms of the SDSD-system (Section 4), Some details of the implemen- 
tation are demonstrated by considering the “GrantGrant right" as an example 
(Section 5). (4) We sketch that even recursive revocation can be integrated into 
the extended SDSD-system. (5) The implementation is available as a prototype, 
implemented in JAVA and CORBA, 

On first sight, our contributions seem technically specific for the SDSD- 
system. However, we emphasize that - independently of the specific control 
system under consideration - the administration of rights always does not only 
have static implications, but also dynamic ones. 
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2. The SDSD-System 

The SDSD-sysicm has been prcsenlcd in [2] and its theoretical foundation 
in [1. 5|. Here, we will give only a short overview of the system. The SDSD- 
system realizes a state*dependent aeeess eontrol in a distributed object system. 
The monitored objects communicate via a CORBA Object Request Broker. 
Every monitored object (also c^)cd functional object) is wrapped by its own 
security object. The functional object and its security object form a so-callcd 
(actual) participant. A method call is permitted if an appropriate dynamic right 
is present. These rights are automatically granted and revoked by the system 
dependent on the current state and based on allowed aciiviry sequences. The 
building components of these allowed activity sequences are triples consisting 
of an activator, an executor and an action. Such a triple, named step, expresses 
that the participant which acts as the executor performs an action (i, e. a method 
call on his functional object) on behalf of the participant which acts as the 
activator. 

The specification of the allowed activity sequences is done with a so-caJIed 
protocol. A formal definition of the language for protocols is given in (3j. The 
core of a protocol is a regular expression on steps. A step specifies a building 
component of an activity sequence and accordingly comprises an identifier 
for the activator, an identifier for the executor and an action (step rule). The 
latter is specified by an action identifier (first action rule) possibly followed by 
appropriate parameters (second action rule and param rules). Though desirable 
in any protocol, parameters have not been generally supported in the prototype, 
but they are needed and actually implemented for the specific types of protocols 
introduced in Section 4. The identifiers used to determine activator and executor 
of a step have to be declared in the remainder of the protocol and arc the so- 
called /omiaf participants. These arc placeholders for the actual participants, 
who act as activator and as executor, and have to be bound before a concrete 
activity sequence is monitored. 

When a new activity sequence should be started in the context of monitoring 
an application, several administration activities additionally have to take plxc. 
Some of them arc under the eontrol of the users of the application, others are 
done by the system, transparently for the users. Figure 1 gives an overview of 
the main activities and the order of their execution. The gray arrows and boxes 
show the functionality of the basic SDSD-system. The black arrows and the 
white boxes show the extensions introduced in Section 3 (et. seqq,). 

First, some user has to specify the allowed activity sequences by declaring 
an application protocol. Next, the protocol has to be instantiated and bound. 
Therefore, another or the same user as before performs the binding activity. 
Thereby, he assigns actual participants to the formal participants considering 
the type constraints listed in the application protocol. As result of this activ- 
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Figure I. Overview of (he main admini&lraiiort acUvilieg (declaring, binding, starting and 
granting) and ihc order of ibeir cxecuiion. The functionality of the basic SDSD*sysiem is 
represented by the gray arrows and the gray boxes, the proposed extensions are represented by 
the black arrows and the white boxes. 
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iiy. h finite automaton is generated, which accepts exactly (hose sequences of 
steps (respectively the corresponding activity sequences) that are specified by 
the regular expression of the proiocol. In the remainder this finite automaton is 
called application automaton. A declared application protocol can be instan- 
tiated and bound several times. After generating an application automaton, it 
has to be started. Therefore, some user performs ihe starling activity, which 
has two effects. First, a distributed representation of the application automaton 
is created and sent to the participants which are involved in that automaton. 
Second a virtual security token "is created”. 

Abstractly seeing, this token dynamically permits the execution of an appli- 
cation activity. Therefore, it is automatically forwarded to the participant who 
acts as the activator of the step which shall be executed next. The selection is 
taken by using the distnbuted representation of the automaton and is described 
at the end of this section. During the forwarding process the token is slightly 
changed, accordingly, in Figure 1 it is called token instance. After completion 
of an application activity the token is appropriately modified and forwarded 
again according to an activity sequence specified in the application automaton. 
In some sense, this token represents tidyruimic right, since it is revoked imme- 
diately alter single usage. After forwarding the token, the execution of a next 
application activity is permitted and so on. When ihe automaton reaches a final 
siaie the sequence is finished, thus the token and the distributed representation 
of ihe automaton are deleted. 

The token and the process of forwarding it from one pariicipani to another 
- as described above - are an abstract explanation of the actually used access 
control mechanism. Technically seeing, the security objects of the participants 
negotiate which application activity is permitted next by interchanging pre- 
defined messages. At first, the executor of ihe lasi executed siep (called last 
executor) sends offer messages to the activators of possible next steps (accord- 
ing to the application automaton). If the functional object of an activator wants 
to execute the action belonging to the siep, the activator answers with ^gei mes- 
sage. The last executor replies to one of the get messages he receives with a pur 
message. This behaviour corresponds to forwarding the token in our abstract 
explanation. The receiving activator sends an invoke message lo the executor 
of the belonging step. The invoked executor executes the action according to 
the siep description. Thus, this step (respectively ihis application activity) is 
completed. Then the invoked executor sends - as the new last executor - new 
offer messages and so on. 

All messages are interlinked by sequence numbers (this, among others, 
changes the token). Furthermore, messages as well as the application automa- 
tons are cryptographically signed and locally logged by the security objects to 
detect security violations. 
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3. Considered Problem and Approacli 

The SDSD-pn>lolype, as reported in [2), only monilors ihe application ac- 
tivides but not the additional administration activities which might be crucial 
for achieving overall security; (1) Declaring Application F*n;>Ux.'oh (2) Binding 
Application Protocol and (3) Starling Application Automaton. In Figure 1 this 
situation is indicated by showing a (gray) “monitoring box” on top of “Execut- 
ing Application Activity” but not on top of the listed administration acdvities of 
the basic SDSD-system (the gray rounded boxes). In this paper we investigate 
in depth the prx>blem of how the listed administration activities can be moni- 
tored by an extended SDSD-system, too. In terms of Figure 1, we will provide 
(the white) “monitoring boxes” for the administration activities such that ap- 
plicadon acdvities and administration activities are homogeneously supervised 
within the new SDSD-system. 

We reconstruct the SDSD-system in a way, that the system offers so-called 
administration operations, which are used within the administration activities 
to accomplish the administration tasks. These operations are: ( 1 ) declare (a new 
application protocol), (2) undeclare (an ^pUcadon protocol), (3) bind {partic- 
ipants to an applicadon automaton), (4) remove {a bound, but not yet started 
application automaton), and (5) start (an already bound application automaton). 

As shown in Figure 1 , the execution of an administration activity is monitored 
by the system (indicated by the boxes above the correspt>nding activity sym- 
bols; undeclaration and removal are not shown there). On a conceptual layer, 
these administration activities are permitted by first level static administration 
rights, Tbese administration rights are granted and revoked - discretionahly - 
by the participants, sometimes directly with the aid of one of the two additional 
administration operations (1) grant (an administration right) and (2) revoke (an 
administration right, more exact: revoke a grant), or somedmes as a side effect 
of one of the other administration operadons. The holder of an administration 
right is able to use it until the grantor revokes the originating grant as an explicit 
action by calling the revoke operation. Calling the grant or the revoke operation 
(revoke is not shown in Figure 1) is an administration activity itself, thus it is 
also monitored by the system. Conceptually seeing, their execution is permitted 
by a second level stadc administration right. 

The set of administration right types is shown in Table 1. The GrantGrant 
right permits the execution of the administration activity grant, whereby the 
GrantGrant right, the GrantEteclare and the Declare right can be granted to 
any other participant of the system. The holder of the GrantGrant right is also 
allowed to revoke the grants caused by himself. The GrantDeclare right is a 
limited version of the GrantGrant right, i.e. granting a right and revoking a 
grant is restricted to the Declare right. A participant needs the Declare right 
to declare new application pr<<ocols or undeclare application protocols that he 
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Abbreviation 


Penniu 


GnmlGrariL 


gg 


graoling gg. gd. d, resp. revoking corresponding 
grants caused by the holder of gg 


CraoiDeclare 




graniing d. resp. revoking corresponding grams 
cBUded by (he boldei of gd 


Declare 
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declaring new ^cocols resp. undeclaring 
protocols caused by the holder of d 


Own 


0 [Protocol prot] 


graiuing b [prot] . s [prot , AutOB&too aut ] . 
■Cprot] . resp revoking corresponding grams 


Bind 


b [Protocol prot] 


ioscandaiing protocol prot (iocl. binding) 
resp. revokiog corrcaponding no( ycl started 
insiances caused by Ute bolder of b [prot] 


Stan 


tfCPtotocol prot] 


staniog akuomatons 

that are instances of protocol prot 


Stan(lAstance) 


■[Protocol prot, 
AutOBaioo tut] 


starling automaton aut 

that is instance of protocol prot 



Table !. Summary of ihe administration ri|ht types. 



has previously declared. The declarant of a protocol becomes the owner of il. 
i.e,, he gets automatically ihe Own rig hi. The owner of a protocol is allowed to 
gram all rights w.r.i. ihe protocol, namely, the Bind right and Ihe iwo different 
types of ihe Stan right and to revoke corresponding grants. The Bind right is 
necessary to instant iaie an application protocol, i.e.. to generate an application 
automaton and bind participants to this automaton. The first type of the Start 
right is solely referring to a protocol prot . The holder of this right is allowed 
to start any automaton that is an instance of prot . The other type of the Start 
right is additionally referring to a specific automaton instance aut, i.e., only 
this automaton instance can be started. Both types do not permit the abortion 
of any automaton, no matter who has started it. In contrast, the holder of the 
Bind right is allowed to remove automatons that he has previously bound. But 
if such an automaton is already started, its removal is forbidden, 

4. Implementation 

In Section 3 we have introduced conceptual static administration rights, 
which conceptually permit the execution of administration activities. These 
conceptual rights are different in kind from the dynamic rights (token) described 
in Section 2. The administration rights are explicitly granted and revoked by 
executing an appropriate administration activity. Furthermore, they can be 
repeatedly used (considering resource restrictions). In contrast, the dynamic 
rights are automatically assigned and withdrawn by the system. The withdrawal 
occurs directly after single usage. 
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To overcome these difTerences. we intRxluce a set of specialized pn)tocols, 
called administration protocols. As shown in the right part of Figure 1, when a 
participani grants an adminisiraiion right to another participant (or to himself), 
an appropriate administradon pn>tocol is chosen and bound (both within the 
binding administration protocol activity). The administration automaton gen- 
erated in that process has two purposes: (1) It permits the grantee (holder) to 
execute all administration activides that are allowed by the granted administra- 
tion right (e.g. grant an administration right to a participant on his own). (2) It 
permits the grantor to execute the activity “revoke the granted right, represented 
by this automaton”. {Actually, as shown in Secdon 5, a special paidcipant Is 
allowed to end the automaton on behalf of the grantor, ) 

Next, this administration automaton is started. Analogously to starting an 
application automaton, a distributed representation of the automaton and a token 
(instaiK*e) are created. From this stage forth, the access control of administration 
acdvities is enforced almost In the same manner as the cxmtrol of application 
activides. Only the selection which activator gets the put message is taken 
differently, namely on the basis of assigned priorides. As shown in Figure I, 
binding an administration protocol and starling an administration automaton 
is not monitored by the system, since these activities are only initiated and 
executed by the system itself. 

Apart from the participants mentioned in Section 2 (in the following called 
functional participants), other so-called special participants participate in ad- 
ministration automatons. These participants provide the operations that are used 
to carry out the administration tasks. There are three different types of special 
participants: Protocol Manager. ProUKolStarter and GrantManager. Partici- 
pants of the first type, for simplification also called F*n:>Ux;olManager (Prokv 
colStarter and GrantManager, respectively), offer the operations for declaring 
(declare) and undeclarlng (undeclare) application protcKols. Operations for 
instantiating application protocols (bind) as well as starting (start) and re- 
moving (remove) application automatons are provided by the Protocol Starters. 
GrantManagers offer the operations for granting (grant) administration rights 
and revoking (revoke) corresponding grants. Furthermore, they gather the in- 
formation on behalf of the functional participants, which administration rights 
those got, by whom and at what time. Each functional participant has exacily 
one GrantManager assigned to him. But one GrantManager can be assigned to 
several functional participants. Special participants do not have afunctional ob- 
ject but only the (normally wrapping) security object. They do not need any user 
interaction. Thus, they can be settled on any host, particularly on especially 
secured hosts. Due to this property, they can be protected against malicious 
changing, therefore they are trustworthy participants. This trustworthiness is 
necessary, because crucial security checks have to be done in the context of the 
administration activities. 
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5. Some Details for (rranting the GrantGrant Right 

Grafliing a right is done by invoking ihe grant operation on a GrantManager. 
During the execution of ihe grant operation an ^propriate administration proio* 
col is bound lo get an administration automaton. This administration automaton 
is ihen started. In ihis section we show some details of ihe GrantGrant right. 
The other rights introduced in Section 3 are treated similarly, as described in 
113|. 

The administration protocol for the GrantGrant right is shown as an automa* 
ton in Figure 2. At this stage, the description of the protocol contains some 
additional information, which will be used during the process of creating the 
administration automaton and binding participants to the automaton. This in* 
formation consists of (1) a list of the formal participants, (2) a list of variables 
and (3) a set of semantic constraints. The list of the formal participants spec* 
ifies the types of the participants, who have to be bound to the automaton. In 
(he case of the GrantGrant automaton these are (i) the grantor, (ii) the Grant- 
Manager that is assigned to the grantor (grantManagerOfGrantor), (iii) the 
grantee called holder and (iv) his GrantManager (grantManagerOf Holder). 
The "assigned to” relations are guaranteed by testing the two is client of 
semantic constraints. In contrast to general practice, separation of duties is noi 
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enforced in the ca^e of binding an administradon automaton. This is neces.saiy 
in the case of granting a right to oneself, when the grantor and the grantee 
are identical. The list of variables defines variables to which values {resp. 
objects) have to be assigned during the binding process. Inter alia, these are 
three objects gg, gd and d, one for every right that can be granted by holding 
the GrantGrant right. The has type semantic constraints guarantee that ev- 
ery object has the correct type according to its name as specified in Table 1. 
The variable automat ID records the unique identifier for this automaton. The 
variable revoke Event is used during the revocation of a right. 

After binding, the GrantGrant automaton is started, i.e. execution of a first 
step is offered to the eligible paidcipants. The holder receives six offer mes- 
sages (see Section 2 for an explanation) to execute a step, one for each step 
in which the holder can act as the activator. Three offer messages apply to 
the steps with the parameterized action grant, and three to the steps with the 
parameterized action announceRevoke. The grantManagerOfGrantor gets 
one offer for the step with the parameterized action enforceRevoke. He ac- 
cepts this offer only if his client. i,e, the grantor, has instructed him to revoke 
the grant that has led to this automaton. If he accepts, the enforceRevoke step 
has the highest priority so that it will be the next step In this automaton. 

By choosing one of the three offered grant steps the holder is able to 
grant the GrantGrant, the GrantDeclare or the Declare right to any functional 
participant. The grant operation offered by the GrantManager of the holder 
expects three arguments. In each case the first two are already set to values 
that are determined during the binding pnx:ess. Considering the preceding type 
informadon (ParticipantClient is the common supertype of all functional 
participants) the argument for the last parameter grantee can be freely chosen. 

By predetermining some values during the binding process, the holder is 
restricted to chtxxie the parameters for the grant operadon suitably according to 
the description of the right he holds. In the present case the first parameter states 
the right that could be granted. With the aid of the second one, the Invoked 
GrantManager is Informed about the fact that the passed holder will be the 
grantor of the grant acdvity that should be performed under the GrantGrant right 
held by the holder. As result of granting the right, the invoked GrantManager 
generates and starts a new administration automaton. In that second automaton 
the grantee of the grant acts as the holder and the grantor of the grant (the 
holder in the first automaton) as the grantor. 

If in the first automaton the holder wants to revoke a grant that he has pre- 
viously caused, he invokes one of the three announceRevoke steps, depending 
on the granted right. The only argument that has to be handed over by the holder 
is a value for the parameter grantEventID. The invoked GrantManager of the 
holder expects an identifier of an automaton that was caused by the grant of a 
right. The holder gets such identifiers as a return value of the grant opera- 
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tion. The other two already sec arguments ensure that the holder is just able 
to revoke automatons that aie caused by his grants. 

The name of the operation aiinounceRevoke expresses the fact that at this 
point the GrantManager (of the holder in the first automaton) is merely charged 
with the revocation. The actual enforcement is done in another automaton, 
because revoking a grant means co end the automaton that resulted from this 
grant. Therefore the GrantManager keeps the necessary information in his 
internal attributes and waits for an offer to execute the enforceRevoke step 
in the automaton, that should be ended. Normally, he has already got such an 
offer, since chis step, resp, its edge, begins at the initial state of the automaton. 
If the holder of the second automaton (who is the grantee in the grant 
step of the flrsc automaton) is accepting his offer, i.e. he executes a grant 
or an announceRevoke step, the offer for the enforceRevoke step has been 
invalidated. But after completion of the grant or announceRevoke activity, 
the automaton will be transferred to the initial state and inter alia an offer for the 
enforceRevoke step will be sent again. When the enforceRevoke operation 
is executed, the GrantManager gets to know that the holder of the second 
automaton (who is assigned to the GrantManager) will lose a right soon. Thus, 
the GrantManager examines within this operation, whether further revocations 
have to be recursively done. Further details of the revocation are presented in 
(3], which also contains a concrete example for using the GrantGrant right, 

6. Related and Further Work 

The idea to administrate an access control system like the SDSD-system 
with the help of itself is very appealing, but there are not many systems with 
this prc^jerty. Mostly, a further higher level access control system is used to 
administrate a basic access control system. In [7] the access control system is 
explicitly decomposed into an enforcement manager and a policy manager. In 
contrast, in the SDSD* system, the administration of the policy is done with the 
help of the system itself. 

A widely known self*administrable access control system is Role-Based Ac- 
cess Control (RBAC, (14]), The administrative layer is ARBAC97 [15] respec- 
tively ARBAC99 [16] (Administrative Role-Based Access Control). It is bised 
on and used for a decentralized administration of Role -Based Access Control 
systems. The administration system is partitioned into different components. 
In ARB AC these components are for user-role assignments, permission-role 
assignments and role-role assignments. These components consist of adminis- 
tration concepts to create, modify and remove those assignments. In the SDSD- 
system, there are similar assignments, but as a difference, the activities leading 
to these assignments are controlled. Another model for self-administration of 
RBAC is SARBAC (Scoped Administration of Role-Based Access Control, 
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[4]), It is also uses RBAC for the cunliol of a RBAC-system, but is somewhat 
different to handle. 

An example for a system with dynamic internal administration of rights is 
Hydra (17], It assigns rights to runtime objects (of the Hydra type local 
namespace) based on rights of the originating static object and based on rights 
of the calling object. The UNIX operation system has also the concept of 
dynamic rights amplification by the suid- and the guid-flag [6). It allows the 
owner of a program to give other users additional rights when executing this 
program. These additional rights are limited to the rights the owner of the 
program already has. But if the owner of the program wants that a second user 
shall grant rights on the program to a third user, the ownership of the program 
has to be transferred to the second user. 

The sepaiadon into the different administration activities Declare, Bind and 
Start has its similarides in Workflow Management Systems [9), There, the 
administration tusks involved in the creation of a new workflow are the speci- 
fication of a workflow process definition itself and the creation and the start of 
a workflow prtx;ess instance. The declaration of a SDSD-protocxd corresponds 
to the specification of a new workflow process definition, and the prwess of 
binding and starting corresponds to the creadon and start of a workflow process 
instance. In contrast to the Workflow Referenc*e Mtxlel, our model explic- 
itly distinguishes between the two tasks of creating and starting a new prwess 
instance. 

Some further work has also to be done: It may be feasible to provide the 
system with the ability to transfer the ownership of declared protocols to another 
participant or to separate the ownership of a prot<x;ol from the right to grant the 
Bind or the Start right by introducing some additional administration rights. 

Our current prototype supports only one ProtcxxdStarter, one ProUxx^lMan- 
ager, one place to store the declared application protocols (Protoad Repository) 
and one place of the not yet started application automatons {Protoa^l Instanc'e 
Repc^sitory), A pc^licy for the visibility aspects has to be specified and an appro- 
priate mechanism has to be developed to overcome this limitation. Furthermore, 
it is desirable that the system supports the abordon of an already started au- 
tomaton, As a first idea, the protocol definition language can be expanded to 
mark states of the automaton {maybe called checkpoints) at which it can be 
aborted in a safe manner. Another important administration activity which is 
not yet included in our system is the introduction of new participants into the 
SDSD-system. This acdvity also might be controlled by another administration 
right. 
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Absiraci; In this paper, we invesiigaie (he aulhorisation service provided by Microsofl* 
.NET MyServices [I]. We propose modificaiions and cxiensions lo extensible 
Markup Language (XML) [2] based daia siruciurcs' schemas to suppK>rt a 
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in (he specification and analysis of a practical application involving access 
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L MICROSOFT .NET MYSERVICES 

Microsoft .NET MyServices [1) is the name for a set of XML message interfaces 
delivered as part of the Microsoft .NET initiative. It is a platform for building user- 
centric Internet applications. It provides a private, secure * 'digital safe deposit box” 
where users can place their personal data. This digital storage box serves as the 
single, central location where users can store, update, and control all of their personal 
data, .NET MyServices aims to provide a fine granularity of control to the user 
(owner of the data) once the information is placed in the digital safe deposit box. The 
user may choose to share that information with friends, family, groups with which 
they have an association, and businesses. Additionally, users can sign up to receive 
alerts on a number of desktop and mobile devices, .NET MyServices is implemented 
as a set of web services that utilise industry standards including XML and SOAP, 
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These services can use .NET Passport [10) to authenticate users and .NET Alerts to 
notify users of important events through a wide range of client devices and to gain 
access to key pieces of data. .NET MyServices aims to provide ownership and 
control of personal data to individual users. 

2. AUTHORISATION SERVICE 

In .NET MyServices. the following items are used in the design of the 
authorisation system. 

The definition of a role in terms of the permissions that it has on different objects 
is specified using a role-template. A role-template defines the set of methods allowed 
by the role-template and the Scope visible to each methcxJ. A role-template has a 
name (e.g. rt 1 ) 

The mapping between the role-template and the user is defined by the function 
“Role". Then the users have a list of roles that are authorised to access the content in 
documents associated with those users. This is defined in role-list, which describes 
what information to share > who to share with and how to share it. 

A role-map describes what information is to be shared and how that sharing is to 
occur. It defines for each role (from the role-list), what the allowable methods are, 
and what scope of data is visible while using this method. The role-map is the same 
for all instances of a particular service, and is authored by the implementer of the 
service. Hence the objective of the role -map is to simplify the security authorisation 
layer as it appears to the end user. It does this by specifying the fixed set of access 
patterns that occur on a given service. 

For schema and examples of role-list and role-map documents, please refer to [3J. 

3. PROPOSED EXTENSIONS TO AUTHORISATION 
SERVICE 

We propose extensions to the existing authorisation system in .NET MyServices 
thereby enabling it to support the following range of access control policies - 
Conditions and Actions based access policies. Role based access policies. Static and 
Dynamic separation of duty. Delegation, Chinese-wall policy and Joint action based 
policies. Jn each case, we will first describe the access policy requirements to be 
supported by the web service, discuss the existing limitations and propiwe extensions 
to data structures and schemas and specify the authorisation service. In describing 
our extensions to the authorisation service, we will use the term “provider" to denote 
an entity that owns the content document (or web service data) and the term “user" to 
denote an entity that accesses the provider's document. Due to space limitations, we 
have not discussed extensions to implement Chinese- Wall policy. Delegation policy 
and 'limited number of accesses’ policy in this paper. They can be found in [4J along 
with a detailed description of our extended authorisation model. 

Through out this paper, when we use the element 'role' in role-list schema 
skeleton extensions, we implicitly mean that it is a role, a delegated-role or a 
dynamic-role. Delegated-role and dynamic-role are defined in the sections to follow. 
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Foi* simplicity, we only show the schema skeleton for 'role’ element. The same 
applies to both methodRef and jointMethodRef elements in role elements in the role- 
list document. For simplicity, we only show the schema skeleton for methodRef 
element. Every .Net My Services provider has a content document that actually stores 
his/her data and an access control list (ACL) document that stores authorisation 
information. We suggest every provider provisioned for a .NET MyService should 
also be provisioned a log document along with the content document and ACL (role- 
list) for auditing purposes. We will not be discussing the auditing aspects in this 
paper. 

To begin with, we propose a small modification to the role-map schema that 
helps to identify uniquely a method-scope pair in the role-template. This is achieved 
by including an “id" attribute. This new attribute is introduced so that this pair can be 
referred to in a role element in a provider's role-list document. We will see later that 
this minor extension will be useful in the specification of fine-grained access control 
policies. An example with this minor extension (in bold) is shown in figure 1 . 



<fcHfMap> 

<hs scope , f> 

<Ns roleterT^laie names 

<hs. method name-'qoery" scope Ref-" I " Id - “ I ’’/> 

<hs;melhod nam^"hisen' scopeRcf-"! " W - “2"A> 

</hs.roleTen)plate> 

<-^foleM9p» 

Figure 1. Role* map extension wilh preliminary extension 

We are now in a position to consider the extensions to schemas and data 
structures that would enable us to support the range of access control policies 
mentioned above. 

3.1.1 Conditioas and Aclions 

The existing authorisation service in .NET My Services does not have the ability 
to specify conditions to methods when performing access control checks. Each role- 
template provides access to a number of methods on various scopes to a user. To 
further restrict access on each of those methods based on arbitrary conditions, we 
introduce a new element methodRef. This cxjnstrucl enables us to associate 
conditions and actions with a method. A method can have a condition and one or 
more actions associated with it. The modified schema skeleton for role-list document 
is shown in figure 2. The elements and attributes introduced to support Conditions 
and Actions based policies are described below. 
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<hs rolel'isi .. >i i 
<hs. scope ... 

<hs'pole.,.>o 
<h$ subject /> 

<hs:meihodRefklRcf= " ">g 

<tisxondkiion operation - ", • {anyj 

<h$.preJtcale name - ..mmm 

<hs:paraTncicr turne® " valuer /nny} 

</hs paTameier> 

</hs.predlca!e> 

<bs:cond ibon opera non = “ . , , ”/>q i--, f-| 

</hs;oondnion> 

<hs: action id = type = . ”>o «im«m 
<hs' predicate name* rtiia 

<h8:parameier name® " . "value® '*>g •ammm {^yl 
</bsiparairteteT> 

<1is.predicale> 

</bs:aclion> 

</hS'meihodRef> 

<hs.eap<TesAt>» i^^s. expires A l> 

{onyl 

obs:roie> 

<.^j rol«[jsi> 



Fi^arc 2. Modified schema skeleton forrole«lisl document 



/roleLisi/rofeAneihodRef element refers to the ID of the method for this role in its 
role-template. Multiple method IDs can be referenced here. For instance. methodRef 
= "1,2". In this case the conditions and actions are performed for the methods with id 
I and 2. /meihodRef/@idRef attribute gives the reference to the method id in the role 
template referred to by this role. 

/roteUst/role/methodRef/condition element is a Boolean formula. If the formula 
evaluates to true then the access is granted. In general, the condition expression can 
involve several predicates involving standard logic operators such as ‘and', ‘or’ and 
‘not*. Defining a condition element within another condition element can specify 
recursion. Each predicate may have one or more parameters, 

A parameter can be specified In three ways: (a) as a string in its ‘value' attribute 
(b) as a list of arbitrary elements and (c) as a single 'function' element. If a value 
attribute is specified, all the child nodes are ignored even though they are specified. 
Also, if some elements other than ‘function' elements are specified, every ‘function’ 
element is ignored even though it is specified. Consider an example of a predicate: 
compare Str(sl.s2,s 3) is a predicate where si is ‘eq’ (equal) or ‘neq’ (not equal) and 
s2 and s3 are two strings to be compared. This predicate compares two strings 
according to the operator. Consider an example of a function: getDateO is a function, 
which takes no parameters, and it returns a text nexJe representing the current dale, 
/roieLisi/roie/methodRef/acnon specifies actions that need to be performed when 
an access request is made to the meth(xJ(s) through methodRef, Each action has an 
ID so that it can be uniquely referenced (using Xpath), The type attribute is used to 
define whether the action is only performed when the access is granted (on_access) 
or is always performed whether or not access is granted (always). The predicates in 
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action expressions aie similar to those defined in conditions except that there should 
be at least one predicate element. 

3.1.2 Role Hierarchy 

One of the advantages of the role-based (RBAC) [5][9] approach is that it can 
model the privileges in an organisation more effectively, A simplistic view of an 
organisation structure is a hierarchical ordering of responsibilities > with the senior 
positions encompassing all the privileges of the junior positions, with some extra 
privileges. Such a role hierarchy can be achieved by providing hierarchy in role 
template definition. At present, most of the services in .NET My Services use only 
about 3-5 role templates and there is no hierarchy. We propose the following 
extensions to NET My Services authorisation service to enable role based access 
control and role hierarchy. Each service should define a dynamic role-map at the 
user level. The role-map should be static at the web service level but the provider 
should be able to change it when needed. Therefore, every provider should have 
his/her own role-map along with the web service role-map. Let us call the provider's 
role-map the provider-role-map (XML document name = providerRoleMap), New 
scopes can now be defined in this provider-role-map instead of in the provider's role- 
list, We also remove all scope definitions from the role-list for a provider and move 
them to the provider-role-map for consistency. Role-templates’ ID in provider-role- 
map should be anything other than rTO, rTl, rT2, rT3 and rT99 as these are the 
default role-template IDs. Every method in the default web service role-map and 
provider-role-map should have an ID number attribute to uniquely identify the 
method. 

When a provider is provisioned to a service, the provider has his or her own 
provider-role-map document along with the content, system, log and acl (role-list) 
documents. The XML Schema skeleton for providerRoleMap is shown in figure 3, 

The schemas for scope, mle-template and their child elements and their attributes 
are the same as for those defined for the web service role-map. Other elements and 
attributes introduced to implement role hierarchy policy are described below. 
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<h$ proviikrRoieMtp chmgeNumbera*. "id“" "cretioi^" ..." 

K inlni.hi**hnp /^Mhemu mi c rmoft.cgm^s/200 1/ 1 C/core’*> i i 
<hs:scqx 

<hs name xml'lang*". ."d^". .">o 
<hs shape ba»*".. ">i i 

*^hs include *elect="...">> .^k.-^< 4 i&:incltjde> 

<hs:exclude sdeci*"...'’>o i , 

</h5:sh8po 

</hsscope> 

<hs.rokTemplaie name-'*...*>« immwm 
< hs fullOeKription xml;lang»~.. " i</hs.ful 1 De$cripiion> 

<hs ' inchideRT name ■ ■*. . ."</hs ' includeRT>(i 
<hs. method nam^"..." scopcRef®" . " u 3 = 

<hs ovcinde riNamc**'.. " idRcf-"...” 

methodName ■ ". " scopeRef"*' .. "/>a 
</hs.ovemde> 

«^/hs . rolcTemplate^ 

</Ks .prov)dcrRolcMap> 

Figure S. Prov ider* role • m ap schema skcleion 

proxiderRoleMofi/roleTemplaieAncludeRT element is used to specify hierarchy, 
A tole-templale can inherit another role-template’s privileges with this element. See 
figure 4. /includeRT/®name attribute is used to refer to the role-template whose 
privileges can be inherited, 

providerRoUMap/rofeTeinpfaie/ov(rrid( element is used to override either a 
scope or method name in a methcxl element in a role-template. This can be used to 
implement role hierarchy as shown in scenarios be]ow. /override/@riName attribute 
refers to the role-template (that is inherited) in which the overriding his to be done. 
If the mentioned role-template is not inherited with an includeRT element, override 
element is ignored. //^verr/tfe/@/t//?e/ attribute is provided to refer to the methcxl 
element (using its ID) from the inherited role-template that is to be overridden. 
/(nemde/®meih*dNain€ is an optional attribute. It is to be used only when the 
method in the inherited role-template is to be overridden, /override/® sc opeR^ifi an 
optional attribute. It is to be used only when the scope in the inherited role-template 
is to be overridden. 

Note that the role templates inherited can either be the default role templates 
from the web service role- map or from prov ider- role-map. To achieve role hierarchy, 
a suitable new role-template (with needed hierarchy definition) in the provider- role- 
map is created. Then it is to be referred in the suitable role element(s) in provider's 
role-list. For illustration purposes, a few scenarios are shown in figure 4. Role- 
templates rtiO, rt20 and rt30 ate defined, rt30 inherits privileges from both rtlO and 
rt20. Method with ID ‘4’ from rtlO is overridden in rt30 to ‘create’, ‘insert’ method’s 
scope from rt20 is overridden to 2 in rt30. 
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<hi roleTempiKe ftair«= "nlO"> 

<hs.fTicihoJ f\amc="qucfy“ scopeRer®”)" id » 

<hs'mclho<J n8mc=*’iTt5cn" 8copcR«f»"3*' id • T’/> 

<hs method neme-’replsce" 9copeRe^“3 " id ““3"/> 

<hs method name="cleleie" scopeRer='T id 
<hs:roleT«mp1aie> 

<hsn>teTemplale name='‘Tl20^> 

<h8:method nime«"qucfy' scopeRef -"5' id - '*r’/> 

<ttS'meihod name-'insert" scope Ref-*' 5'* id = “2"/> 

</li8:roleTemplale> 

<ti8 roleTemplale name-'‘n30"> 

<i>5 includeRT name * "it I (y*> 

«^hs.incliideRT name - “il2D"> 

<hs oveiride nNamc-'PllO" idK«1«"4" 

meihodName ■ '"creaie" /> 

<rts ovemde riNamc - “n20" idRef - "2" seopeRcf ='2" » 

<hs me^tod n eme="quefy" scopcRcf="4" Id - " I "> 

<h$ method names’inaen" 8copeRef»''4" id * "2"f> 

<hs.mctood namc-"rtpUe«" scopeRef-'d' id = “3"/> 

</hs roleTempUtO 

Figure 4. Role*iemplaie example with role hierarchy policy 

3.1.3 Dy namic Separation of duty 

Dynamic separation of duty (6] can only be determined during system operation. 
This is whereby a user having chosen a specific action or role at run time is not 
auihonsed to perform another action or assume another role. To begin with, the user 
is allowed to perform either ol the actions or assume either of the roles. We achieve 
dynamic separation of duty by adding a new element called 'dynamicRole’ to the 
schema ofrole*lis(. The modified schema skeleton for role-list document is shown in 
figure 5, 

Extensions to the role*list schema are described below: 

/roleUsf/dynamicRole element is introduced to support dynamic separation of 
duty policies. Most of the child elements and attributes lor (his element are exactly 
the same as for ‘role’ element. Therefore, only the new added elements and attributes 
are described here. /dynamicRole/RT - A minimum of 2 (or more) RT elements 
should be used in each dynamicRole element. Tliis element encapsulates both role- 
template and the scope on which it is used along with the conditions and actions on 
the methods. The user with a dynamic -role has access to any of the role- templates 
and on any of (he scopes provided by the dynamic-role. The role-template - scope 
pairs are mutually exclusive. Once the user accesses a role-template on a scope 
(through a RT element), s/he is not allowed to access any other privileges provided 
by his/her other RT elements, /dynamicRole/RT/scope Ref Qi^meni stores the scope to 
which the user has access with the role-template in this RT element. 
/dynamkRole/RT/roleTemplateRef element stores reference to one ol the role* 
templates’ ID to which the user has access. 

/roleUsr/dynumkRole/useJRT/ element is used (o store information (o enable 
dynamic separation of duty. /usedRT/iJRefelem^ni stores the ID reference to one of 
(he RT elements (in this dynamic-role). Until the first time the user accesses any of 
(he privileges in his/her RT elements, this is a null element. Once the user accesses 
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privileges provided by any of the RT elements, the ID of that RT element is written 
here by the authorisation service. 



<hsiTOl€Usi ..>11 

<hs:scope 
<hsTo1e . . /> 

<hs:dynainicRolc scopeRe^".. * ToleTemplBleRef*'' *' .. >9 



<hs:iubjeci ... /> 

<hrRTid-‘'. 

<hs:scopeRef>« i</hs.scopcRef> 
<hs'roleTemplareRef>i i</hsToleTemplateRet^ 
<hs:methodRer idRef = 

<h6;ccrdiiion ot^Wion , 

</hs.Gondit>on> 

<ti$;aclioo id = type = ,”>® Motaiai 

<vhs;action> 

<iftt'meihodRef> 

</hsRT> 

<usedRT>c 1 
<)dReC>i i<^idRef> 

<A*«dRT> 

<h8'expireaAOo i</h8:expiresAi> 

{onyf 

</hs dynam ic Rc le> 

<'hsiroIel,i8i> 



Figures. Modified schema skeleton for role-list document 

All the methods in every RT element in a dynamicRole element implement at 
least the 'check Access' predicate, which does the following: 

When the user accesses one of the role -templates (provided by the RT elements) 
on the scope allowed for the first time, it sets the idRef element in usedRT to the 
RT's ID. 

Next time a user with dynamicRole element tries to access a scope with a role- 
template provided by any other RT elements, access is denied. Access to RT with ID 
stored in usedRT element is only allowed. 

3.1.4 Joint Action Based Policies 

Joint action based policies [7) are used in situations where trust in individuals 
needs to be dispersed. Often this arises because individuals are trusted according to 
their expertise, which in turn maps the concept of trust to a specific set of actions. In 
delegation, there is a partial or complete granting of privileges, whereas in joint 
actions agents may acquire privileges, by working together in tandem, which none 
posses in isolation. 

Consider the following example. A patient is admitted to the hospital if both the 
patient and a doctor agree, Thai is. the policy is that the doctor and patient jointly 
need to agree for the action “admission of the patient to the hospital" to be 
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aulhorised. Modified XML schema skeletons for providet-role-map and role-list 
documents are shown in figures 6 and 7 below. 

Schema extensions to ptovider-role-map document are as follows: 
providerRoUMap/roleTemplate/jointMeihod element is added to a role-lemplate. It 
defines a joint method and its quorum number. Its name, scopeRef and id attribute 
schemas are the same as method element’s schema. They are not redefined here. 
/jointMethod/quorumeXtmeuX. gives the authorisation system the quorum number for 
this joint method. Quorum is the minimum number of users that have access to this 
joint method via the same role-template and call the joint method for it to be 
performed. Till the quorum is reached, a temporary flag is set in their role element as 
defined below. 



<h$ Drovi<lerRoWMdp . >i i 

<hs:$cc9e /> 

<hs CWP_$ets .../> 

<hsi<ii«T«iTipiate ntrne-" 

<hsdull Descrip! ion xmhltng®" i<^:f\i1IDescrrpiion> 

<hs: includeRT na me = . "</hs . includeRT>a 

<h$;meihod name**'. scopeRef*'*, .*' id * 

“ ">o 

<hs;ovefride methodName * 

scopeRef®" . , , id = 

<hs:jo I nlMelhod name scopeRef ■ " " id" 

<hs'quonim>i i</hs:quomm> 

</hsjoinlMethad> 

</hs:iokTemplaie> 

</h6*prcvider RoleM ap> 



Figure 6. Modified schema skeleton for provider*role*inap document 



Schema extensions to role-Usl document are as follows: 
/roleList/roIe/joiruMeihodRef: There are as many joinlMethodRef elements in a role 
element as there are Joint- methods in the role-template it is referring to. It is similar 
to a methodRef element expect that it has a boolean flag element. All other elements 
are exactly the same as those defined in methodRef schema, /joiniMeihodRef/@idRef 
aiirihuie refers to the joint method's ID and is used to refer to the Joint-method in 
this role's role-template, 

/roleLisUroie/jiuntMethodRef/condition/fliig element is used to store if joint access 
request is made, /condition/flag/reducedScope is an optional element. It may so 
happen that a user should gain authorisation only to perform a Joint action on a 
further reduced scope than that permitted by her role -template. This scope element 
solves such purpose. Its shape element's schema is the same as shape element's 
schema for scope element in role-map, /condition/flag/value element is by default set 
to false. When the request for the joint-method comes in from the user (with this role 
element), this element is set to true. Until the quorum is reached only the flag in the 
joint-method elements in different users' role elements is set to true. Once the 
quorum is reached, the actual action is performed on the content document of the 
provider. 
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<hi role(.i$i . >11 
<hs;scope . . 

<hs.rol« ... >• ..MKM 
<hj.subj«t 

<h5:jomlMcth^Rrf idRef ■ >o k«M«a 
<hs'Ctf)didoAopersiion 
<hs;R8ff»i I 
<hs.rediicedScope>Q i 
<hs 5hap«base“"...*>i i 

<h$ lnclud« inclu4e> 

<hs actecr®". ,»»o,w,j</h$:excludo 

<^:shape> 

</h&.reduced^cope> 

<hi.v»lue>i i<1is.valye> 

<hs:nag/> 

<hs.prcd)cate name . .y>i iMawd 
<h5xoodwor operation - " . ">o </tis*condilion> 

<hs action />« miMiiim 
<^h&.jolniMeiho<lRef> 

<hs:TnethodRer 

<hs.cxpiresAP*« i</hs«xpire$AP» 

{nny! 

<A\rrok> 

<Vh«:rolcUst> 



Fiyurt ?. Modified .'schema skeleton forrolc-lisidocumcm 



A new predicate 'checkQuorum' is defined for all services that need to 
implement joint action based policy. Every jointMethodRef element in a role 
element must at least call this predicate in its condition, 'checkQuorum' predicate 
does the following: 

• Whenever a call to a Joint method is made, it checks the number of flags that are 
set to true in the role elements that have access to this joint method via the same 
role-template the caller has access to, 

• If the number of flags set to true is more than or equal to the quorum number 
mentioned in the Joint method definition in the role-template, then the actual 
change is made to the content document. Or else the flag in the caller’s 
JointMethodRef element is set to true. 

4. AUTHORISATION EVALUATION 



The ,NET My Services authorization algorithm is redefined here to into account of 
the extensions proposed to the authorisation service as follows. Please see [1] for 
original authorisation algorithm. 

The user, application and platform identities as well as the credential type are 
determined from the incoming message. The matching role from the provider's role- 
list document is then located, if a matching role or dynamic-role is not found, then 
the request fails with an authorisation fault. If a matching role is found and if it 
contains an expiresAt element, then the role is checked to see if it has expired. If not, 
then the role- template that is referenced by the role is found from the role- map or 
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provider-role- map. Thl^ lemplate is checked to see if the melhcxi requesled is 
allowed. Using Ihe scope from the role-map or providet-role-map (referenced by 
role-lemplale), combined with the optional scope referenced by the role, the node set 
that is visible to this message is determined. 

If a matching dynamic-role is found, and if it contains an expiresAt element, then 
the dynamic-role is checked to see if it has expired. If not, the idRef element's value 
of usedRT in the dynamic-role element is checked. If the idRef element’s value is 
null, the role-template and scope referenced by first RT element are located from the 
role -map or provider-role-map that is referenced by the dynamic-role. This template 
is then used to determine whether the method or joint-method requested is allowed. 
The scope is used to determine if the operation requested is within that scope. If 
either the method is not allowed or the operation is not within the scope, then the 
role-template and scope referenced by second RT element are located. Then whether 
the method or joint-method requested is allowed by the template or not is determined 
as well as whether the operation requested is within that scope for all other RT 
elements. If none of the role-templates and scopes allows access to that requested 
method on the requested scope, then the message fails with an authorisation fault. 
The usedRT' s idRef element is set to the value of the id’ attribute of the RT element 
that c*ontains role-templates and scopes with privileges requested in the message. If 
usedRT' s idRef element's value refers to an RT element's ID, and if either the 
method is not allowed by the role-template in the RT element or if the operation 
requested is not within the scope allowed, the message fails with an authorisation 
fault. Using the scope from the role-map or provider-role-map, combined with the 
optional scope referenced by the RT element in the dynamic-role, the node set 
visible to this message is computed. 

If the method requested is a normal method, all conditions are evaluated and if 
any one returns false, then a fail message is sent. All the actions with ‘type’ set to 
“always ", are performed. All the actions with ’type" set to “on-access’" are only 
preformed if condition is true. If the methcxJ requested is a Joint-method then there 
exists at least one predicate (checkQuorum) in the condition element. The condition 
is evaluated. If it returns false, the message fails with an authorisation fault. If not, all 
the actions with 'type' set to “always"', are performed. All the actions with ‘type" set 
to “on-access'" are only performed, if condition is true. The requested operation is 
then performed ensuring that the user has no access to information outside the scope 
computed above, 

5. PRACTICAL APPLICATION 

We have applied the proposed extensions to the authorisation service by 
developing an access control system for electronic patient records. In this section, we 
only briefly describe some of the various access policies mentioned above in Section 
4 that have been specified in this system. For a detailed description of the system 
and the authorisation policy specification, refer to (4J, 

In our demonstration, we assume that an electronic Patient Record System (PRS) 
is used by several hospitals in a metropolitan city. Hence each hospital is the 
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provider und palienls are users. A patient record is stored as a XML dcKument. In 
this paper, we will not describe the structure of the patient record. We are currently 
preparing a separate paper on this complete system. 

Examples of the role hierarchy policies specified in this system - A Receptionist 
Rose can create a patient's name in a blank medical record, A Nurse Nancy can read 
a patient’s general information and has Receptionist privileges. A Doctor Alice can 
read entire medical record. Doctor also has Nurse and Receptionist privileges. A 
Doctor in charge Bob can not only read but also write to record and informed 
consent sections. However, he can only write once into the informed consent section. 
He also has Doctor's privileges. This scenario is achieved by intrrxJucing new role- 
templates and then creating the required role hierarchies using these templates as 
described above in Section 4, 

We have specified both static and dynamic separation of duty policies. In the 
static case, for instance in the role hierarchy example above, the duties of a nurse, 
doctor and doctor in charge are statically separated by creating role-template 
elements for them in the provider-role-map and then referring to them (or directly 
referring to the default role-template elements from the role-map) in the role- list for 
the provider - in this case all the hospitals. In the case of dynamic separation of duty, 
we have policies such as doctors Doug and Lee can write a report after a medical 
procedure or certify it but not both. That is, one doctor should not be able to both 
write a report and certify it. Depending on the action taken by a dcx:tor, access is 
controlled in a dynamic fashion. 

In terms of the Chinese-wall policy, the PRS has patients grouped into hospital 
name and department categories as shown below. 

Set A: Departments (Cancer research. Cardiology. Neurology) 

Set B: Hospitals (ABC Hospital, PQR Hospital, XY2 Hospital) 

An example in our system occurs when a hospital implements Chinese-wall 
policy on trainee debtors when they access the patient records. Trainee debtors may 
do research by accessing patients records from only one of the departments from Set 
A and from only one of the hospitals in Set B. Once a trainee doctor (Tom) accesses 
a d<x;ument from a category say Cardiology from Set A, he is not allowed to access 
any other category from that set. Similarly if Tom accesses a record from ABC 
Hospital, he is not allowed to access patient records from any other hospital from Set 
B, Note that here we have patient records from multiple hospitals. 

Our system has different examples of the delegation policy. A simple one occurs 
when a doctor Alice delegates part of her privileges to her personal assistant Patricia. 
Note that this is a case of partial permanent delegation. This is achieved by adding a 
delegated-roie to the appropriate provider's role list. An example of a joint action 
policy in our system is as follows: A discharge medical report can only be certified 
by two dcKtors jointly, for instance, the duty doctor in the hospital and the patient's 
surgeon. Once again this is achieved using the constructs specified in Section 5 
involving role-templates and role elements and a Boolean flag. 
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6. CONCLUDING REMARKS 



In Ihis paper, we have considered Ihe auihorisalion mcxJel in .NET My Services 
and discussed Ihe limitalions of Ihe auihorisalion service in lerms of Ihe policies that 
can be supported. Then we proposed new extensions lo Ihe XML data slruclures* 
schemas thal could help lo support the specification of a range of commonly used 
access policies in commercial systems. In particular, we have provided new 
extensions for supporting conditional authorisation, role hierarchy, dynamic 
separation of duly. Chinese-wall policy, joint action based policies and limited 
number of accesses to objects. We have developed the modified access evaluation 
algorithms that lake Ihe proposed extensions into account. We have then discussed 
Ihe application of the modified authorisation service to an electronic Patient Record 
System. We are also currently investigating the extensions proposed in this paper to 
extend the XACL [8] and creating a distributed authorisation service for XML Web 
Services, 
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Abstract A Viriual Commimiiy is a composiUon of hcierogeneous and indepen* 
demly designed subsystems, focusing on large*scaJe resource sharing. 
One of the key aspects of virtual communiiy management, is how lo en- 
force a controlled and selective sharing of resources in such a dynamic 
and decentralized environment. The traditional way is to have all the 
access requests mediated by a trusted third-party. However, this ap- 
proach has the drawback that the third party can become a bottleneck 
for the whole system. By contrast, in this paper we propose a decen* 
traJized approach to virtual community management that relies on a 
controlled sharing of rights and duties among communiiy members. In 
the paper, besides dealing with communiiy policy specification we pro- 
vide a framework able to manage aJl the phases of the the communiiy 
life. 

Keywords: Virtual communities, decentralized systems, selective and controlled re- 
source sharing, policy specification. 

1. Introduction 



A Viriual Communiiy is a composition of hcierogeneous and indepen- 
dcnlly designed subsyslems, focusing on large-scale resource sharing, in- 
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novalivc applications and in some cases high performance computation. 
The sharing that we refer to is the direct access to computers, software, 
and data emerging in fields like science, industry and engineering. Sev- 
era! open issues need to be addressed, such as how to manage access 
policies to coordinate resource sharing, how to establish a community, 
how to ensure that member communities respect community policies 
and so on. Protocols to define how to establish sharing relationships 
between participants must also be enforced: each member entering into 
a community has to agree on what it is permitted to do and also what 
it is obliged to do. Resource sharing must be carefully controlled, with 
resource providers and controllers defining clearly and carefully what is 
shared, who is allowed to share and the conditions under which the shar- 
ing occurs. Resource sharing is therefore conditional, each provider has 
to define and publish the conditions under which it makes its resources 
available. Such conditions (or policies) must always be consistent with 
the community policies, regulating the whole organization. Further, once 
resource sharing is defined, the member is obliged to give access to its 
services according to the stated rules. Since the need to set up a collab- 
orative sharing of resources is fundamental to many diverse disciplines 
and activities, our work focuses on suggesting a broad class of strate- 
gics to establish an efficient virtual organization. The goal of our work 
is thus to define an overall architectural framework for a collaborative 
environment, characterized by a flexible and dynamic structure where 
participants share resources in an efficient and decentralized way. The 
principle wc apply to address decentralized control is based on the con- 
cept of sharing rights and duties among all members of the community. 
In particular, wc introduce the concept of witness, that is, a community 
member that can act as a trusted third party monitoring the exchange 
of resources between two parties. Different from other proposals [4. 6j 
the witness can dynamically change and is not empowered to control 
all community issues, thus it cannot become a bottleneck for the whole 
system. Decentralization of respons abilities is obtained through the use 
of administrative credentials. Indeed, in addition to the witness, we also 
introduce the concept of community guard, that is. a member respon- 
sible of accepting or refusing the joining of new members. Due to lack 
of space, in the paper wc mainly focus on the basic components needed 
for enforcing a controlled sharing of resources in a virtual community. 
Related work (c.g.. [4]) mainly focus on how to manage decentralized 
policies for heterogeneous resources that are not under a centralized 
control. However, none of them addresses issues as members entitle- 
ments, delegation of entitlements, violation detection, and sanctioning 
mechanisms [5). By contrast in this paper we deal with some of these 
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aspects and devise strategies to setup communities in an effective and 
decentralized way. The remainder of this paper is organized as follows. 
Next section presents the basic elements of a virtual community. In 
particular. Section 2.3 presents the policy language we have developed 
to encode community and local policies. Section 3 deals with processes 
underlying a community. Finally. Section 4 concludes the paper. 

2. Basic Elements of a Collaborative 
Environment 

Formally, a collaborative environment CE can be modelled as a tu- 
ple (iS,v4C,R,A^<9), where 5 is the set of subjects belonging to the 
community. R the set of shared resources, and AC represents the set 
of administrative credential types defined throughout the commu- 
nity. Finally. NS is the normative state, that is. the set of policies, 
directions and rules regulating the community. We assume that our 
framework supports a key-managemeni infrastructure such as VersaKey 
[7], where exh subject is actually identified by its public key certificate. 
Moreover, exh subject is qualified by means of credentials. Credentials 
are digitally signed certificates issued by trusted third parly authorities 
slating properties and allribulcs of their owners. In what follows, we 
illustrate the basic building blocks of a virtual community. 

2.1. Administrative credentials 

Subjects of a CE can act as service providers as well as service con- 
sumers, and also, under certain conditions detailed in the following sec- 
tions. community controllers. To regulate the assignment of roles across 
the community, the community also relies on a set of pre-defined admin- 
istrative credentials AC that correspond to specific roles that need to be 
played by one or more community members for the correct functioning 
of the community. The number of subjects to which each administrative 
credential is assigned can vary from 1 to fc, where k denotes the whole 
population, on the basis of the rules defined in the normative state. Un- 
like traditional credentials, administrative credentials are issued by the 
community itself when the subject subscribes to the organization. Both 
conventional and administrative credentials are expressed using an XML 
based language [2]. The administrative credential types we refer to are 
the following: 



Resource provider. It is the credential assigned to all the subjects shar- 
ing their resources xross the community. A resource provider can 
cither directly manage disclosure and xcess to its resources, or 
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delegate this task lo one or more resource managers, by issuing 
administrative credentials. 

Resource Manager. It is the credential assigned lo all the subjects 
entitled lo manage a resource by a resource provider. Resources 
managed by a rcsoiure manager can belong cither lo the commu- 
nity or to a third party that delegates resource administration. 
The corresponding credential will specify the name of the subjcci, 
a link to the profile of the resource it manages, and the owner of 
the resource who delegates Ihc resource management, 

W/mc^.t.This credential type is assigned lo subjects entitled to monitor 
that a specific resource request by a subject lo a service provider 
has been correctly processed according wilh bolh local and com- 
munily policies, A wiincss must Ihcn be able to detect possible 
community laws violalion as Ihey occur in the processes it wit- 
nesses. Witnesses can also be in charge of exercising additional 
functions, for instance, they may also randomly control sharing 
processes that they do not directly witness. 

Community guard. It denotes Ihc members empowered lo accept or 
refuse the joining of new members, A communily guard has Ihc 
task of cvenlually issuing administrative credentials to the appli- 
cants, Moreover, il is in charge of checking compatibility of ap- 
plicant local policies with community laws and, under certain cir- 
cumstanccs, certifying the validity of local policies. 

The above set of adminisirativc credcnlial types can be cxiended when 
needed. Each subject may pos.scss one or more administralive creden- 
dals. The set of members possessing a specific adminisirativc credential 
can share a special key lo exercise administrative fund ions. Once the 
member receives one of the adminisirativc credentials and the corre- 
sponding key, it is authorized lo execute all the associated functions. 
The whole description of righls and duties associalcd wilh each admin- 
istrative credential is formalized into a set of XML documents published 
in ihe communily repository. In the following given a subject s C S ^nd 
an administrative credential type ac € AC we denote by belong{8,<tc) 
the fact that s is associated with a credential of type oc. 

2 , 2 . Community resources 

The key element characlerizing a community is the set of resources 
shared by its members. Resources lypically have differenl enquiry mech- 
anisms and capabilities that vary according with resource characlerislics. 
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Since different policies can be adopted to regulate each type of resource 
we first need to provide a taxonomy of resource types. However, because 
of the rapidly growing number of collaborative applications and the rapid 
evolution of distributed systems the adopted resource characterization, 
borrowed from [3], is partial and open to update. The set CR of resource 
types we refer to consists of the following elements: CR={ Computational 
Resources. Storage Resources, Networkresources, Code Resources, Cara- 
logs]. To make policy specification easier we assume that each resource 
is uni vocally identified and has a set of characterizing properties that 
can be exploited in the specification of policies. For instance, a stor- 
age resource can be characterized by space availability, disk bandwidth, 
the types of data that can store, the mechanisms used for file transfer 
and backup. Like for subjects, resource properties are collected into 
credentials associated with the resources themselves. Resource creden- 
tials are issued by community guards when the corresponding resource 
is included into the set R of resources shared across the community, and 
they are stored at resource providers site. In the following, when no 
further specification is added, with the term credential we refer to sub- 
ject credential, whereas we use the term resource credential to refer to 
a credential associated with a resource. Resources may either belong to 
community members or to the community itself. Resources belonging to 
specific members are called local resources, whereas resource belonging 
to the community arc called community resources. Local resources arc 
under the owner control, however their administration can be eventually 
delegated to other members via administrative credentials. 

Example 1 Suppose that a University has esiahlished a coUahoraiion 
with a research center and a laboratory to cooperate on a common re- 
search project. Suppose moreover that the project is sponsored by EU and 
that the consortium has bought hardware and/or software instruments 
with EU funds. Such resources are an example of community resources. 
Moreover, suppo.’te that the participating laboratory makes available its 
server for storing community data. The server is then an example of 
local resource. 

Resources can be further classified into on-duty and on-choice re- 
sources, depending on whether the corresponding providers are obliged 
to share the resource or can deliberately choose to share them. When 
a community resource is added one or more members are chosen to act 
as providers, and therefore they are in charge of administering the re- 
source. All community resources are on-duty, since they must be granted 
to community members and can not be released for use on discretion of 




ConiroUed Sharing of Resources in Vinuat Communities 



181 



their managers. By contrast, local resources can be either on-duty or 
on-choice, depending on the statute in force and on member availability. 

2.3. Virtual community policies 

Sharing resources across a virtual community must be regulated by 
both communin' and local policies. Local policies are basically expressed 
in tenn of properties and capabilides that requesters have to possess in 
order to obtain resources. Such capabilities are stated as conditions 
against the requester credendals. Community policies are access control 
policies regulating access to resources belonging to the community itself. 
Besides local and community policies, sharing of resources is also regu- 
lated by community directions, which arc high-level instructions defining 
minimal condidons that resource providers have to sadsfy while granting 
local and community resources within the community. Both community 
policies and direcdons are part of the normative state of the community, 
as explained in Section 2.4. Directions can be of two different kinds. 
positive or negative. Posidvc directions quantify the resources that must 
be shared, specifying who must be granted the access and, eventually, 
the frequency or the direction validity. By contrast, negative directions 
are used to specify denials such as services not pennitted across the 
community or subjects that must not be allowed to receive some re- 
sources. Since directions only give some general instructions, resource 
providers are allowed to enforce more specific policies as long as they do 
not conflict with any community direction. A community direction can 
be formally defined as follows, 

Deflnition 1 (Community direction). « {5, N 5) 

a virtual community, and let CR he the set of resource types character- 
izing R. A community direction cd is a tuple of the form: 

(lypeR, resq. temp, credsei, sign) where: 

-type R € CR denotes the type of resources to which the direction refers 
to: 

• resq (resource quantification) specifies the set of conditions that providers 
of resources of type rypeR must satisfy: 

- temp is a temporal expression denoting a time interval or a periodic 
expression, specified according to the formalism propo.sed in [Jj: 

- cred.set is a set of credentials identifying the subjects to which the di- 
rection refers to; 

- sign € Ipositive, negative] specifies whether the direction is negative 
or positive. 

Resq is expressed as a set of conditions against resource properties speci- 
fying the features of the resource that has to be granted. Such conditions 
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are expressions of the form "property_name op a" , where property_name 
is a resource properly (cooiained in the corresponding profile), op is a 
comparison operaior, and a is a consianc or an expression compatible 
wiih ihe properly value, Noie chat ii is noi required to coostraini all ihe 
elements of a resource credeniials. Properties thai are noi constrained 
can be autonomously regulated by local policies of resource providers. 
The Credset component is a sei of credeniial type names denoting cre- 
dentials needed by subjects in order to be able to axess the resource 
under ihe specified conditions. Finally, the time interval component de- 
fines the period the direction has to be enforced, and/or the frequency 
(e,g., every Monday) the resource must be available for sharing. Credset 
and temp are optional elements. When they are not specified they can 
be locally regulated by resource providers. 

Example 2 Suppose that a university grants both students and profes- 
sors 10 gh of disk storage during the academic year. Moreover, suppose 
that students are not allowed to store file containing gif images and can 
not use fast internet providers during week-ends. The corresponding di- 
rections are formalized as follows: 

- (diskStorage, size = lOgb, [1/1/2003, 1/1/2004), {students, 

teachers}, positive) 

• (diskStorage, datatype = gif ,|l/l/2003, 11/1/2004], {atudeats}, 
negative), 

- (Network, bandwidth = 256 Kb, (Saturday, Sunday), (a tudent a}, 

negative), 

The second and the third directions are examples of negative directions 
constraining resources available for students. 

We assume that community directions are enforced for all community 
providers. However, Definition 1 can be easily extended to keep track 
of the service providers to which the direction refers to. We assume 
that community directions are always consistent, that is. it is not pos- 
sible that community directions are in conflict among themselves. This 
means that we assume ihai consistency of directions is checked each time 
a new direction is added or an update occurs to an existing direction. 
Policies regulating disclosure of resources can be either strong or weak. 
Strong policies regulate disclosure of on-duty resources, that the mem- 
bers are obliged to share. Strong policies are digitally signed by a com- 
munity member entitled to perform such a ta.sk (typically a guard or a 
community founder), which signs them when the corresponding resource 
is added to the list of on-duty resources and the corresponding resource 
credential is issued. 
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Example 3 Referring to Example 2. consider a mass storage provider 
obliged to share 10 gb of its hard disk. Since the sharing of resource is a 
condition for membership, the corresponding policies will be strong and 
local. 

Each time a strong policy for a local resource is entered or needs lo be 
modified, it must be validated by the signature either of a guard or of 
a community founder.which checks its coasistency with the community 
directions. Updates can be executed on provider initiative or to comply 
with new community directions. Referring to Example 2. if the direction 
changes asking for 15 gb of disk storage, all the corresponding policies 
that conflict with this new direction have to be updated by the providers 
and validated by one administrator entitled to sign strong policies. Sim- 
ilarly. community strong policies are updated upon proposal by one of 
the managers of the resource, but the updates need to be validated by 
the whole set of managers. 

Weak policies arc local policies defined by providers for governing on- 
choice resources. Such policies govern disclosure of resources that the 
provider is not obliged to grant. Providers can autonomously update 
weak policies without asking for any validation by community adminis- 
trators. They only have to inform the other members whether an update 
to the policies occurs broadcasting a message to the rest of the commu- 
nity, In case of a not conect enforcing of weak policies, sanctions will 
be lighter than in case of no conect enforcing of strong policies. 

Example 4 Suppose that the server of Example 3 makes available 25 
gb of its hard disk. The J5 gb offered in addition to the 10 gb that the 
server w obliged to grant are regulated by local weak policies. 

Policies are formally defined as follows. 

Definition 2 (Policy). Let CE « (5, NS) be a virtual commu- 
nity. A policy p for CE ft a tuple of the form: 

{Tfrescond. subjeond, grade, time, type), where: 

• r € H denotes a resource ID: 

• rescond is a list of conditions on re.tource credentials, specifying the 
features of the granted resource: 

- subjeond is a list of credentials and/or credential properties, staling 
credentials and conditions against them that must be .’taiufied in order 
to obtain access to r; 

- lime denotes the validity period of the policy: 

- grade € (strong, weak) specifies whether the policy refers to an on- 
duty. or on- choice resource: 
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- v^pe € {local, communiry) denotes whether resource r belongs lo a 
member or lo the community itself. 

The component rescond of a policy specifies the resource actually shared, 
constraining the properties of the released resource or the features of 
the service granted. Since each resource is identified by a credential the 
list of properties consists of the attribute and tag names contained in 
the corresponding XML credential. The component subjcond specifies 
the subject credentials and conditions on them that requesters need to 
possess in order to obtain r. Such conditions are expressions of the form 
" attribute _name op a'\ where attribute _name is an attribute name, op 
is a comparison operator, and a represents a constant or an expression 
compatible with the attribute value. The last two components of a policy 
specification specify the grade and the type of policy and must be always 
specified. By contrast, components time and subjcond can be omitted 
from the policy specification. If the subjcond component is omitted it 
means that the resource may be granted to all the community members, 
whereas if time is not specified, it means that there are no temporal 
constraints for granting the resource. 

Example 5 With respect to the community direction of Example 2, sup- 
pose that a storage provider makes available ISgb of its disk storage, 
identified by code DSJ, for teachers and JO gbfor students. The corre- 
sponding policies are the following: 

1) (DSl, size = 10 gb disk, {students, teachers (grade = full)}, 
strong, local); (0Sl,size — 6 gb disk, teachers (grade = full, 
dep s biology], weak, local). 

The first is an example of strong policy since it regulates the portion of 
disk storage the server is obliged to grant. By contrast, the second policy 
is an example of weak policy. The policy states that only full profes.^ors 
of the biology department can access the 5 gb of memory in addition to 
the amount granted by the previous policy. 

Community directions and policies therefore work together to grant a 
correct functioning of the whole community. Directions have higher pri- 
ority than local policies and therefore in ca.se of conflict they take the 
precedence. For instance, a community direction can oblige network 
providers to provide a fast connection every day from 8 a,m. to 10 p.m. 
Each storage provider is empowered to autonomously define under which 
conditions it grants the service but it should assure the continuity of the 
service during the specified hours. Intuitively, a policy is in conflict with 
one or more directions when its enforcement can cause a violation of the 
direction. More precisely, a policy and a direction may conflict when: 
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♦ The policy forbids a resource access co a member which is entitled 
CO access it by a positive direction. 

♦ The policy allows some of the ax«sses permitted by a positive di- 
rectioo to a member, but the conditions specified in the policy are more 
restrictive chan chose stated in the corresponding positive direction, 

♦ The policy allows resource axesses that are explicitly prevented by 
a negative direction. 

Example 6 With respect to Example 2 consider the following policies: 

i . (PRO V 1 , bandtri dtb » 2 56Kb , { atudent s } , jMonday -SftturdayJ , at r ong, 
local); 2. (D 81 , 8 gb disk, {studants), strong, local). 

Suppose that the first poUcx is specified hy an internet provider, stating 
that it grants fast connection to students from Mondax to Saturdov. This 
policy conflicts with the last negative direction of Example 2 which denies 
the access on Saturdax, Moreover, suppose that the storage provider of 
Example 5, updates the first policy reducing the disk storage availabilitv 
from 10 to 8 gh. The resulting policy will he in conflict with the first pos- 
itive direction of Example 2 hut not with the negative one, which forbids 
storing gif files. 

When a conflict is detected, the provider is obliged to rewrite the 
conflicting policy. If it refuses to comply with this obligation it is conse- 
quently sanctioned, usually with the revoking of the provider credential 
for the involved resouices. Note that since weak policies do not corre- 
spond to providers obligations they can never be in conflict with any 
positive direction. Finally, community policies community directions, 
typically when a positive direction is updated influencing the validity of 
the community policy. Community policies also may need to be updated 
in order to be correctly enforced. As discussed earlier, in order to be 
modified such kind of policies need to be validated not only by a single 
community manager, but by all the managers administering the same 
resource. 

2.4. Normative state of the community 

Previous work [5] introduced the concept of normative state as a set 
of access permissions of community members, and their obligations to 
provide access to their services. We extend such concept defining the 
normative state as a set of information about the community structure, 
regulating not only resource management but also policy enforcement. 
More precisely, the normative state contains community directions as 
well as policies regulating access to community resources. Additionally, 
it includes all those kinds of information that help the members to ac- 
tively participate to community life. Such information concern aspects 
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like the managemeni of the community, sanctioning mechanisms and 
violation punishments. The normative state can be divided into three 
sections conesponding to three different kinds of information concerning 
respectively resource sharing, management structure and enforcement 
mechanisms. 

Resource sharing. The core of such section is the collection of commu- 
nity directions (described in Section 2.3) giving instructions concerning 
policy specifications for the shared resources. Community policies arc 
also included, regulating access to those resources belonging to the entire 
community. Moreover, this section collects summary information on the 
resources shared within the community. More precisely it contains an 
entry for each shared resource specifying the owner, the type of resource 
and whether the resource is governed either by strong or weak policies 
(i.e„ the member is obliged or not to share the resource). Finally, for 
each resource the section also lists the member entitled to manage (e.g. 
Resource manager) and control accesses to the resource itself. 
Managemeni informaiion. This section collects information defining how 
authorities and responsibilities are, or can be. distributed within the 
organization. For what concerns how authorities are distributed this 
section keeps track of the administrative credentials assigned to each 
subject. Moreover it specifies rights and duties associated with each 
administrative credential type and the criteria to assign administrative 
functions to each member. To this purpose, several approaches can 
be adopted. A possible approach is constraining the ratios of members 
that must be authorized to exercise administrative function to the whole 
population. Another criteria might require that each member must be 
associated with at least one administrative credential, or establish the 
minimum percentage of members that must be assigned to each ad- 
ministrative credential. The specified constraints impacts the degree of 
decentralization enforced within the community. Intuitively, the more 
members are authorized to exercise administrative functions the more 
decentralized will be the resulting community. 

Sanctioning mechanisms and violation detection. The last section of the 
Normative state defines how to detect and manage cases when members 
fail, or do not comply with community laws. More precisely, such section 
contains a classification of the possible violations with the related sanc- 
tioning mechanisms, and a description of the devised mechanisms and 
protocols to detect the violations. Unlike the description of the devised 
mechanisms, which arc expected to be standardized for all the communi- 
ties, the classification of illegal actions strictly depends on the reference 
scenario and the type of environment considered. 
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3. Community management 

To explain how we resize a decentralized system enforeing a controlled 
and sclecdvc sharing ofresourecs we now briefly detail the management 
process underlying a community. The steps we focus on arc community 
setup, that is, how a community is started, new member association, 
that is, how new members can subscribe to a community, and, finally 
the process of leaving the community, that is, leave of a member, 

9 Community setup S^cveral issues have to be addressed in order 
to setup a new community. First, a community is said to be estab- 
lished when the minimal conditions to concctly execute sharing of 
resources hold. Operatively, community founders have to publish 
a first version of the normative state, defining the set of adminis- 
trative credentials and choosing the founders that will receive such 
administrative credentials. Moreover, resource credentials specify- 
ing resource properties must be issued to the resource managers 
for each resource of the set R of shared resources. The first issue 
facing community founders is then to decide key aspects of the 
normative state that better fit the community goals. In order to 
define a framework that is as adaptable and flexible as possible we 
do not define a unique type of community. Indeed, our framework 
supports the definition of several community types, regulated in 
different ways, and can be properly customized according to spe- 
cific community requirements and needs. 

■ New members association One controversial issue about how 
to join a community regards the entities with whom the requesters 
have to interact. In centralized systems such task is performed by 
a specific entity which has the control of the whole community. To 
avoid centralized approaches where reliability of the whole com- 
munity is entrusted to a single entity in our framework this role 
is played by a set of members referred as community guards (or 
guards, for short) whose specific task is to perform the joining 
phase. This phase is actually carried out as an interaction be- 
tween the applicant and a guard. The aim is to verify requester 
properties in order to accept or refuse the subscription. Moreover, 
community guards eventually sign local strong policies of the ap- 
plicant, in order to certify policies consistency with community 
directions. A guard can also assign administrative credentials, on 
the ba.sis of evaluation of applicant competences and capabilities. 
The phase starts when a requester contacts a subject of the com- 
munity to join it. If the receiver is not a community guard the 
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request is forwarded to a member having the communiry guard 
credenliaJ, 

■ Leaving the community There are two different ways to leave 
the community: voluntary leave or forced leave. According to the 
first, a member announces that it is leaving forwarding a leav- 
ing message to all community members. The remaining members 
update the normative stale, and delete on cascade all informa- 
tion about the leaving member. Moreover, if the leaving member 
was either a community administrator or a resource provider, it 
is deleted from the corresponding lists, and all the administrative 
credentials il owns are revoked. The second way is the heaviest 
form of sanctioning provided by the community and consists of 
banning. As well as for voluntary leaving, to exclude a member 
all information concerning it must be deleted from the normative 
slate. Note that if the member was an administrator and the com- 
munity makes use of a community public key for signing adminis- 
trative credentials a new key must be sent out according with the 
adopted key management system [7|. The remaining participants 
can then use the new key for exercising administrative functions, 
but not the member which jusi left. 

4. Conclusions 

In this paper we have presented a flexible framework for managing 
virtual communities whose goal is resource sharing based on selective and 
flexible policies. In the paper we have mainly focused on the language to 
specify policies and directions, and on the steps to deal with the various 
phases of the community life. The work presented in this paper is pari 
of an on going research project. We are currently working on XML 
policy specification and on web services for policy management. Also, 
we are developing mechanisms lo check local policy correctness against 
community policies. Finally, another interesting area to explore concern 
protocols and strategies lo share resources among community members 
in a flexible a decentralized manner. 
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Abstract Workflow systems arc today used in numerous business application do> 
mains including office automation, finance and banking, as well as in 
scientific application domains, for automating their day«to*day appli* 
cations. Often, organizations establish a set of security policies that 
regulate how the business process and resources should be managed. 
For reasons of ease in management, these securily policies are expressed 
in terms of rolex. In addition to simple authorization rules specifying 
which subjeci/role can execute a task in a workflow, many business 
processes require support for more complex authorization con.strainis, 
such as xtparaUon of duties. In this paper, we present an approach 
that supports Jtlega/ion and assign users to roles in such a way that 
no constraints are violated. In particular, we introduce the notion of 
delegation consistency and propose algorithms to assign tasks to users 
such that they guarantee delegation consistency. 



Keywords: Access control. Workflow Systems, Delegation 



1. Introduction 

Workflow management aims at modeling and controlling the execu- 
tion of business processes involving a combination of manual and auto- 
mated activities in an organization. Workflow systems are today used 
in numerous bu.siness application domains including office automation, 
finance and banking, as well as in scientific application domains such as 
in spatial processes and DNA sequencing, for automating their day-to- 
day applications. A workflow is defined as a set of coordinated activities 
that achieves a common business objective [1]. An activity, or a task, is 
a logic step or description of a piece of work that contributes toward the 
accomplishment of a process [7. 5j. Tasks that build up the workflow are 
usually related and dependent upon one another, which in turn are spec- 
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ified by task depemiencies. A workflow management system (WFMS) is 
a system that supports process specification, enact menl. monitoring, co- 
ordination and administration of workflow process through the execution 
of software, whose order of execution is based on the workflow logic [1]. 

The desired security to ensure the secrecy, correctness and integrity 
are adhered to a business process and are specified through a set of 
security policies, which are commonly used to define constraints that 
regulate how the business process and resources should be managed. For 
reasons of ease in management, often these security policies are expressed 
in terms of roles. In addition to simple authorization rules specifying 
which subject/role can execute a task in a workflow, many business 
processes require support for more complex authorization constraints, 
such as separation of duties (SOD) (4. 8). 

In [2]. Bertino et al. present a language to express these different types 
of authorization constraints as clauses in a logic program, and propose 
solutions to verify the consistency of the constraint specification and to 
assign users and roles to tasks of the workflow in a such a way that no 
constraints are violated. In this paper, we extend the work presented 
in [2] to support delegation in secure workflow systems. The basic idea 
behind delegation is that an active entity in a system, called delegator 
delegates authority to another active entity, called delegatee, to carry 
out some functions on behalf of the former. In the context of workflow 
systems, delegation amounts to transfer of duties of executing a task 
within a workflow. We call this task the delegated task. 

In case of delegation, one must ensure that no authorization con- 
straints are violated due to the delegation activity. We illustrate the 
problem of the inconsistencies due to the interplay between authoriza- 
tion constraints and delegation by considering a simple example. 

Example 1 Let W he a workflow, which represents the process of re^ 
viewing a paper for a conference, consisting of three tasks {Ti,T 2 iT 3 } 

Assume 7\ refers to submitting a paper. Tj refers to preparing three 
reviews, and 7a refers to collecting the reviews and making the final 
decision to accept or reject the paper. The obvious dynamic separation 
of duties constraints in this example include: (J) Though anyone among 
the set of reviewers may he a reviewer, for any given paper, the three 
reviewers have to he different individuals, and (2) an author cannot he 
the reviewer for his own paper. Now suppose that a user. John, wishes to 
delegate the duty assigned to him to one of his colleagues {Jane). Such 
a delegation is legitimate and may prove valuable as Jane may have 
better expertise on the topic of the paper. However, if the delegation 
is entertained without taking the authorization constraints into account, 
a violation of the constraint may arise. A violation occurs if John is 
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assigned u> review a paper coauthored by Jane, and he further wishes to 
delegate it to Jane. 

This paper is organized as follows. Section 2 reviews the workflow model 
and the authorization rules proposed in [2], Section 3 presents our work- 
flow delegation model. Section 4 provides an overview of the different 
phases of our approach, that are delegation consistency analysis phase, 
planning phase, and runtime phase which are further described into Sec- 
tion 5.6. and 7 respectively. Section 8 concludes the paper and outlines 
future work. 

2. Authorization Constraints in Workflow 

2.1. The Workflow model 

As in most WFMSs. we assume that a workflow consists of several 
tasks to be executed sequentially. 

Each task is a.ssociated with one or more roles, which are the only 
ones authorized to execute the task. In the remainder of this paper. U, 
7Z and T denote the set of users, the set of roles, and the set of tasks in 
a given workflow, respectively. Additionally, Ut denotes the set of users 
authorized to play role We refer to the association of roles with tasks 
in a workflow as workflow role specification, formally defined as follows. 

Definition I (Workflow Role Specification) A workflow role speC' 
ificaiion W ft a list of task role specifications [TRSi,TRS 2 , . . ,TRSn], 
where each TRS, is a triple (T,, where Ti € T « a task. RSx Q 7Z 

is the set of roles authorized to execute and act, € T is the number 
of possible activations of task T^, 

In the following, we use the term workflow and workflow role specifica- 
tion as synonyms, A workflow may have several workflow instances. We 
assume that each instance inherits the same workflow role specification 
from the workflow from which it is generated, 

2.2. Constraint language 

Authorization constraints, used to express security policy, are defined 
as clauses in a normal logic program [6]. Such language is not intended 
as the end-user language for expressing constraints but it is internally 
used by the system to make it easy for analyzing and enforcing con- 
straints, However, a visual programming environment can be developed 
on top of this language along the lines of the system discussed in [3]. In 
|2]. authors present a constraint language semantics to formalize specific 
information about the workflow. Such semantics is built upon sets of 
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predicate symbols denoted as speciftcution{SV), execution (EP). plan- 
ning (PP) and comparison (CP) predicates. Constraints are expressed 
as rules of a logic program. An authorization rule ar is an expression 

of the form: H ^ Ai,. . . not n,m > 0, where 

H, Ax,.. ,,An and are atoms and not denotes negation by 

failure [6]. H is the rule head, whereas A\, , . , , An, not B\,. , . , Bm 
the rule hoJ\\ 

For instance, the rule arj= cannot -d 0 t,(C/i,T 2 ) *- execute,i(t^i,T 2 ,fc), 
states that if user Ui has been assigned more than k times for executing 
task 72, it cannot be assigned any longer for Tj 

We call Authorization Constraint-Base of a workflow W {ACBiW)), 
the set of rules specifying all the authorization constraints associated 
with W. Given ACB{W) for a workflow W. it is possible to compute the 
set of roles/users that must be prevented/obliged to execute a task In 
the rest of the paper, we denote as Denied Jloles{Ti), Denied.Users{Ti)^ 
Obliged.RolesiTi), Obliged.UsersiTi) these sets, 

3. The Workflow Delegation Model 
3.1. Delegation Predicates 

In this section, we formally introduce the delegation predicates, VV, 
as the set of predicates used to specify the different types of task dele- 
gations in a workflow. We categorize them into the following two types 
* delegation predicates (QV) and volunteer delegation predicates (VP) 
where VP = BPOVP. 

Delegation Predicates: The predicates belonging to BP contain dele- 
gation predicates as well as the predicates for rejecting delegation. They 
comprise delegateAu{Ui,Tk,Uj)y which a user Ut delegates to user 
Uj all the instances of task T* assigned to him/her by the WFMS, 
delegate Uu{UtyTi^) which expresses the intention to delegate Tfc 

without specifying the delegatee user, reject jield{UiyTie) by which (/i 
rejects instances of 7fc delegated to him/her by any other user and finally 
TejectjkLtn{Ui,Tg,Uj) rejecting only Tfc delegated tot/, fromt/j. 

Moreover. BV contains two additional predicates: 
del€gate^m{Ri,Tie,Uj) aviddelegat€.rr{R^,Tk,Rj)xh&t, differently from 
the others, cannot be specified by any workflow user, but are reserved to 
the workflow administrator. These predicates specify that the instances 
of task Tic assigned to users belonging to role /?, are redirected to user 
Uj or any users belonging to role Hj. Those predicates allow the admin- 
istrator to temporarily change the possible task instance assigned to a 
role without modifying the basic authorizations. 
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Volunteer Predicates: Similar to the delegation predicates, il is possi- 
ble lo define volunteer predicates, W. 

Volunteer predicate. allows a user {Uj) to nomi- 

nate himself for the execution of a certain number (n) of instances of 
a task (TV) that have been delegated by another user, perhaps based 
on certain incentives he/she may receive due to such an activity. We 
provide this capability because we believe that it is not realistic for a 
user to nominate himself only for tasks delegated by a specific user. To 
make this specification more realistic, we enhance the semantics of the 
language with a parameter that allows the user to set a maximum limit 
on the number of delegated tasks he wishes to volunteer for. 

3.2. Delegation Rules 

We use the formalism introduced in section 2 and the delegation pred- 
icates (PP) to define delegation rules. Formally: 

Definition 2 (Delegation Rule) A delegation rule is of the form dr : 
H *— L]y , . . ,Ln, where H is a delegation predicate and i « 1 , . . n is 
either an execution or a delegation literal. 

Given a delegation rule dr, in the following we will use Delegator (dr), 
Delegatee (dr) and Task [dr) to refer to the Delegator User, the Delegatee 
User and the Delegated Task of the delegation predicates in the left hand 
side of dr, respectively. 

De^uition 3 (Constraint-Base) Let W he a workflow. The DelegO‘ 
tion Consiraini'Base associated with W (written DCB{W)) is the set 
of delegation rules. The constraint base of W. denoted as CB{W) = 
ACB{W)UDCB{W). 

4. Overview of our Approach 

In this section, we provide a roadmap of the methodology adopted in 
this paper to support the issue of delegation in secure workflow systems 
so that no authorization constraints are violated. Specifically, we address 
the problem of assigning roles and users to tasks of a workflow such that 
both authorization and delegation rules are satisfied. Our methodology 
is organized according to three phases, as shown in Figure 1, 

1 Static Analysis Phase: In this phase, we analyze the consistency 
of the delegations. The consistency analysis is in turn organized 
done in two levels, internal and external. The internal analysis is 
to determine if there are inconsistencies in the delegation rule base 
(i.e., DCB{W)) itself. External analysis is to determine if the del- 
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Figure y. Pha«s in con5^iraims authohzaiion and enforcement 



egalion rales can be enforced without causing any inconsistencies 
when authorization rules are also enforced. 

2 Planning Phase: The goal of this phase is to generate role and user 

assignments to tasks before the workflow execution. Note that 
while much of the role-task assignment can be done during this 
phase, a complete user-task assignment cannot be done prior start 
executing the workflow. This phase comprises of two sub-phases: 
(I) The Role Planning Pha.’se. in which we employ an exhaustive 
algorithm to generate a Role Assignment Graph rep- 

resenting all possible role assignments for each task in the work- 
flow. (ii) The User Planning Phase, in which we employ a heuris- 
tic approach that plans assignments of users based on RAG[W) 
and authorization rules in ACB{W). We denote the graph gener- 
ated as a result of this process by User Role Assignment Graph. 
(URAG(W)). 

3 Runtime Phase: The goal of this phase is to select an authorized 
user according to the rules in C8{W). In the sub-phase, referred 
to as Task Activation Phase, the delegation rules are enforced and 
the inconsistencies among rules are resolved. Then, the task can 
be executed by the assigned user. The runtime phase, which is 
executed for each task of the workflow, is terminated with the 
Task Termination phase, which prunes URAG(W) with the results 
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of the task execution and prepares the system for subsequent task 
assignments, 

5. Delegation Consistency Checking 

In Section 3, we have defined delegation as a set of logic constraints. 
Here, we develop the formalism to help verify the consistency of these 
rules with respect to the overall workflow specification. This analysis is 
carried out statically as well as during the runtime. The Staiic Analysis, 
addressed in this section, aims at resolving conflicts that arise indepen- 
dently from a specific instance of the workflow. This check can be done 
statically in the sense that it does not depend on the execution history 
of the workflow. The analysis conducted during the runtime phase iden- 
tifies and resolves inconsistencies arising for a particular assignment of 
users to tasks in a workflow. We address this runtime evaluation part in 
Section 7. 

Intuitively, CB{YV) is said to be staiically consisient with respect to 
delegation, if all the delegation rules do not result in violation of any 
authorization constraints. The first type of static inconsistency arises 
when there is a cycle in the specification of delegations. A delegation 
cycle occurs when users' intentions to delegate a task creates an infinite 
loop. Although it is not an inconsistency in its strictest sense, it is im- 
portant to identify such condition as well because it effects the feasibility 
of executing a workflow. 

In addition to identifying cycles in delegation rules, the static analysis 
check aims at evaluating inconsistencies that arise among delegation 
and authorization constraints in the workflow. For example, assume 
the rules cannot jio^{John.T\) •— and delegate J.u(JaneyT\, John) *— 
belong to the model of a C0(W). In this ca.se, an inconsistency can be 
statically discovered since John cannot be delegated for T\ under any 
circumstances given that he is not allowed to execute T\. In order to 
verify the consistency among the delegation rules and the authorization 
rules, i.e,, in CB(W), the following concepts are introduced. These define 
the set of possible users that can delegate, volunteer or being delegated 
for a given task T| : 

• Deiegator.Ustu{Ti) = |J {uj | delegate.f(uj,7i) € C6(W) OR 
delegateJu(uy,T^,Ui) € C8{W)] Delegator.U8ers{Ti) represents 
the set of users who wish to delegate the execution ofT^ according 
to the rules in CB{W)\ 

■ Delegatee.User8(Tt) = I delegate. tu € CB{W)] 

Delegatee. U$er$(Ti) represents the set of users who have dele- 
gated by some other users according to the rules in C5(VV); 
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■ Volunt6eT.Ustrs(Tx) = U{^i I ^folunteer.iu € C8{W)} 

Volunteer^U8€rs{Ti) represents the set of users who volunteer them- 
selves for the execution of instances of 7^, according to the rules 
in CB{Wy, 

It is important to ensure that users who cannot execute a task arc not 
allowed to delegate, being delegated and volunteer for the execution 
of the task. Furthermore, it is necessary to verify that users who are 
supposed to execute a task should not delegate it to some other user. 
The above requirements are formalized in the following definition. 

Definition 4 (Delegation Consistency) 

We say that CB{W) is consistent with respect to delegation if and only 
if the following is verified: V7i € W, 

■ //Obliged.Uwrs(TJ ^ 0, then 

(Belegator.Users^Ti^ 0 belegatee.Users^TJ^ - Obliged -Users 

= 0 ; 

■ If Denied -Users (T^) = then 
Denied.UsersfTj^ 0 Delegatee-Users/TJ » 0; and 

■ Denied .Users H Volunteer -Users 0. 

6. Planning phase 

The planning phase generates the set of possible roles and user as- 
signments to the workflow tasks so that all the authorization constraints 
are satisfied. This phase is performed statically, i.e. before the workflow 
execution starts, and aims at both providing an initial plan and reduc- 
ing. as much as possible, the number of operations to be accomplished 
by the system at runtime. Planning is accomplished in two subphases: 
role planning phase and user planning phase. 

6.1. Role Planning phase 

Our approach to identify role assignments for a given workflow W is 
similar to the solution proposed in [2]. It begias with the assumption 
that the number of roles associated with a task is not large. Therefore, an 
exhaustive approach is taken where all the possible combinations of roles 
assigned to the tasks arc evaluated against the authorization constraints. 
To keep role planning feasible, we assume all the task activations be 
executed by the same role. However, at runtime we relax this assumption 
by letting different task activations assigned to different users. The result 
of this phase is the Role Assignment Graph, RAGiW), defined as follows: 
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Definition 5 (Role Assignment Graph) 

Lei W = (TRSiiTRS^, . . . ,TRSn] ^ workflow role specificaiion with 
TRS, = (Tj, (RSi, acti), 1 = 1. .... n. The Role Assignment Graph of 
W (RAG(W)> is a labeled graph G = {V, E) defined as follows: 

• Vertices. There is a vertex labeled Ti 6 TRSj, /?; € RS^ 

only if the assignment of role Rj to task TJ does not violate the 
authorization constraints. A vertex labeled thus states that 

role Rjcan he assigned to task during the workflow execution. 

m Edges. There exists an arc connecting to (Th^Rfi) only if 

assigning task Ti to a user belonging to role and assigning la.’tk 
Th ttser belonging to Rfc for the same woHcflow instance do not 
violate any constraints. 

RAG(W) contains a path {(ri, Ki) . . . {Tr^, At)) as- 

signments of Ri to Ti, t = 1 ... n do not violate any workflow constraint. 

Example 2 Con.uder a worl^ow W with three ta.<:ks T = (T^Tj.Ts) 

that can be executed by u.sers belonging to roles {Ra, Rc}, respectively. 

Suppose C8{W) contains the following rules: 

ari= cannot jk>r{Rc,Ti) 

arj* cannot jiOr{Ra>Ti) 1), 

ara* cannot -ti 0 r(Rc,T 2 ) , and 

ar4= oannatAOr(RfiyT:i) *— execttter{Ri^,Tjy\) RAG(W) generated ac- 
cording to Definition 5 is as shown in Figure 2. The selected nodes and 
paths are all the ones consistent with respect to the rules in C5(W). 
For instance, there is no edge between and (TajR*) in RAG(W) 

.since it conflicts with rule ar4. 




Figure 2. the RAC{W) gcneraied for ihe workflow in to Example 2 



6.2. User Planning Phase 

In a workflow, it is quite common that Ihc number of users is much 
larger than Ihe number of roles. Specifically, Ihe number of users as- 
signed lo a role significanlly increases as we traverse from higher level 
roles lo lower level roles in Ihe role hierarchy. The exhaustive strategy 
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described in Section 6.1, can no longer be applied to user planning since 
the number of possible users assigned to a task can be very high. There- 
fore, we chose to execute user planning completely at runtime. However, 
even though we do not do user planning in advance, we statically enhance 
RAG(W) with more information to speed up the runtime phase. To ac- 
complish this, we introduce Vser-Role Assignment Graph. URAG(W), 
Essentially. URAG(W) is an enhanced and sometimes instantiated ver- 
sion of RAG(W) with information concerning which users belonging to 
a given role must or must not be assigned for the execution of a task. 
Briefly, in this pha.se. we evaluate rules which are not influenced by the 
workflow execution so they can be verified in advance, and if it is the 
ca.se that a user belonging to a role must execute a task then each 
node (Tk, Rj) to RAG(W) is updated with such information. We denote 
the node representing such users with Analogously, each node in 
RAG(W) is complemented with infonnation about the set of users that 
must be prevented from executing that task, according to the constraints 
specified by the static rules. We denote the node representing such users 
with Formally, URAG(W) can be defined as follows: 

Definition 6 fUser-Role Assignment Graphs Lei RAG(W) he a 

Role Assignment Graph for a worlflow W » (TRSi»TRS 2 TRSnj, 

where each LetCBs{^)he 

the set of static rules belonging to CB{W), The User- Role Assignment 
Graph of W. URAG(W). is a labeled graph G = (V, E) defined as fol- 
lows: 



■ Vertices. 

There exists a vertex labeled Vk = users >t/oiue) /<>'' ^och 

Rj) € where users and value are defined as follows: 

- (fAuthijttr = (u\mustjexecuU^(UyTi) *- beiong(u,R^) € 
C5s(W)} ^ 9 ihen users := i4ut/tyjer» ^txlue = +; 
Otherwise 

- IfAuihus^r = {u(cGnnof,do,,(u,7’J belmgiUyRj) 

€ CBs(W)] ^ 0, then users , = Auihuatr^ and value = 

— If cases I and 2 do not hold, then users » 0, and value = -. 

■ Edges. 

There exists an arc from Vm » (75 , Rj, users(um), vaiue(um)) 

Vfi ^ (Tfi, Rky Uaers(t;n), vcfue(Vrt)) only if there exists an arc from 

{TuRj)io (TH,Rk)in RAG(W). 

Example 3 Consider the workflow of Example 2. and assume that 
CB(Vil) contains the static rules 
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rt =5 {(Tnust^x€cut€u(utyT 2 ) •— beiong{Ui,RA),Ui = {John. Jane]), 
and rj = {{cannotjiOv{Ui,T:i) *— belong{Uj,Rc),Uj= {Boh, Bill]) in 
the model. The resulting URAG(W). generated according to Definition 
6. is presented in Figure 3. 




Figure 3. The URAOf^) for Example 3 



7. Runtime Phase 

The runtime phase is executed upon task activation and termination. 
It consists of two phases: the Task activation phase executed before the 
actual execution of the task to define users assigned for carrying out the 
activities, and the Task termination phase, executed after the termina- 
tion of the task to update the workflow with the task’s execution results 
and to prepare URAG(W) for subsequent task assignments. 

Task activation phase: The check in this phase entails verifying 
several conditions in order to identify the user authorized to execute a 
task Tj. In this phase a user (or several users in case of multiple task 
execution) is assigned to taskT;, First, this phase identifies a candidate 
role ajnong the ones authorized to execute Ty We call the node 
and floie{7ifl4a) its referred node. Second, from the system 

selects a possible candidate user (t/o,,). Two cases are possible here: 
if valueiuasg) = +i then Uqm has to be selected from txsers(n„ 5 )j if 
value(nc, 99 ) = -i otherwise needs to be picked from all the users 
belonging to Role(nass) except from the ones in U5ers(n4,,>. Finally, be- 
foresending Ti to for execution, the system needs to verify that no 
inconsistencies arise between Uass rules in CB{W) having the same 
task in the head and in one of the execution literals of the body (such as 
example cannot jU>^{Bob,Tt) *— eiecufe«(i?o6,T,)), Those constraints, 
defined as Recursive rules in the following, cannot be evaluated before 
or after the process of assigning tasks to user in a workflow. 

To evaluate a rule in Recur siveiT,], we use an hypothetical reasoner. 
For example, to determine whether the execution of the task T» by user 
Uj would violate i?ecur5iue(T,), we insert into C5{VV) the rules, called 
A ssignm en t Hypo ih eses, exe cute ^ (uj * T, , ^ and sue c e 8 8 (7\, k ) . 
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There nile.s allow evaluation of Recur 9ive{Tt). If successful, the candi- 
date user is entitled to execute Tj and the hypotheses can be removed 
from CB{W). Otherwise. Uj is not authorized to execute Ti and the 
process continues selecting another user among the ones available. 

Task Termination phase: This is performed after task execution. 
During this phase, information about the user who has executed the task 
is insened into CB{W). Rules 

^xecut^r{Role(niua)jTj,k) and executeu(u«j>7j, fe) ^ are added 
to CB{W) and used by the system to update nodes in URAG(W) upon 
the evaluation of Sirnple(Tj) using the same methodologies presented in 
section 6.2, 

Delegation Rule Application. The peculiarity of delegation rules, 
which are a special case of recursive rules as described before, is that 
these rules can only be evaluated after a user has been actually assigned 
for the execution of a task. In other words, until the assignment process 
is finished where a user Ui assigned for 7^, t4,^s (Delegator) intention to 
delegate Tj to some other user Ufc (Delegatee) cannot take place. The 
reason why the system should be prevented from applying delegation in 
advance, is to eliminate the possibility of overcoming the authorization 
system by delegating a task to an unauthorized user. 

Different assumptions can be made in case of role-delegation since 
they are defined only by the workflow administrator. To improve the 
performance of the assignment process, their evaluation is applied as 
soon as a Delegator Role is selected by the system as a candidate for 
executing the task. 

The process of evaluating user delegation rules, is applied as soon 
as a user has been successfully assigned for executing a task. It starts 
with a check as to whether a delegating rule exists in the model which 
formalizes the user intentions to delegate the task. If such rule exists, 
the system first identifies a delegatee user and then verifies that the 
delegation does not violate any recursive rules. To determine a delegatee 
user, we provide three progressive solutions. First we look at the user 
specified in the delegating rule. If delegatee is not in the rule or the user 
is not authorized for the task, we examine the volunteer users. Finally, 
if the model does not contain any volunteer user, we extend the search 
to all the users authorized for the task. 
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H. Conclusions and Future Research 

In this paper, we have presented an approach lhal provides support 
for delegation in workflow systems in such a way that no authorization 
constraints are violated while entertaining delegation. 

Currently, we are working on several extensions to this work, which 
are briefly explained below. We are currently extending our work to in- 
clude several types of conditions that specify under which circumstances 
a delegation can occur (such as time related and workload related situ- 
ations). In fact, while this paper proposes a solution where delegation 
is considered for all the instances of a given task, we are aware that 
in reality a person might wish to nominate someone for a work under 
certain circumstances. However, even if we did not present this here, 
our approach is carved in such a way that it can be easily extended to 
address these different types of conditions. Additionally, we plan on ex- 
tending the our approach to verify if a given task can be delegated or 
not and when the right to delegate can be transmitted to another user. 
We intend to introduce the concept of Delegation Access Control av 
sociated with a task that is independent from the workflow. This will 
enable delegation to be enforced over several workflows, including inter- 
organizational processes, in a decentralized manner. 
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MODIFYING LDAP TO SUPPORT PKI 
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Abfiiraci; One of (he impedimenis (o a ^vucce^fstut roll oiJl of public key infrasiruciures 
(PKIs), U ihai Lightweight Directory Access Pn>iocol (LDAP) directories do 
not fully support PKIs. In particular, it is not possible to search for X.5(W 
attributes (certificates or CRLs) that match user defined criteria. Thi.s paper 
de.scribes (he various approaches (hat have been suggested for enabling users 
to search for X.S09 attributes, namely component matching and attribute 
extraction. The implementation of attribute extraction in the OpenLDAP 
product is then described. 

Key words: X.509, p u bl i c key certi ficates, attrib u te certificates, CRLs, PKI. LDAP. Search 



I. INTRODUCTION 

The Lightweight Directory Access Protocol (LDAP) [1| was originally 
conceived as a simplified version of the X.500 Directory Access Protocol 
(DAP) [4]. X.500 was designed to be a general purpose repository for 
storing (mainly communications related) attributes of entities, including 
security attributes such as public key certificates (PKCs) and certificate 
revocation lists (CRLs). However, during the simplification process of 
designing LDAP, many features of the DAP were lost, including the ability 
to fully support public key infrastructures (PKIs). In particular, whilst X.500 
DAP could support the searching for and retrieval of public key certificates 
based on their contents. LDAP could not. For example, a Search such as find 
the encryption public key (i.c. keyUsage extension is set to 
keyEncipherment) for the user whose email address (i.c. the SubjectAltName 
rfc822Name) is A.B.Person@someUni.ac.uk, cannot be supported by LDAP, 
LDAP is unable to perform this search because it does not know how to carry 
assertion values in the protocol. Worse still, the original LDAPv2 did not 
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have a correct way of encoding public key certificates or CRLs for storage or 
retrieval. 

The original LDAP protocol was based on encoding fields of the DAP 
ASN.l [9] protocol as ASCII strings [2| for carrying over TCP/IP. However, 
only selected fields from the DAP were chosen for encoding in LDAP. (This 
is why LDAP is called Lightweight,), DAP on the other hand uses the Basic 
Encoding Rules (B£R) [10| for encoding its protocol elements for transfer, 
so it is not necessary to specify how any particular field is encoded, 6ER 
automatically specifies this for all fields Thus X.500 DAP automadcally 
knows how to encode and transfer public key certificates and their assertion 
values that are defined in X.509 [8], since they arc specified in ASN, 1. 
X,50fi DAP inherently knows the structure, contents and transfer encodings 
of all current and future PK.1 attributes and extensions that are or may be 
defined in X,509 (as long as they continue to be defined in ASN.l). 

Additions to version 3 of LDAP [7] rectified many of the shortcomings of 
the original LDAP, ajid allowed LDAP servers to correctly store ajid retrieve 
X,509 attributes, but searching for them was still impossible. This is because 
the X.509 attributes arc simply transfened and stored as binary blobs by 
LDAPv 3, with the server having no knowledge about their structure and 
contents. Further, no string encodings were specified for the assertion values, 
so that it still remains impossible to Search for X.509 attributes containing 
specific fields, A fuller description of the limitations of LDAP when used to 
support PKIs is given in [1 1|. 

Since LDAP has become the primary way of accessing X.500 based 
directories, and is supported by all the major vendors, e.g, Microsoft. 
Netscape, IBM, Novell etc., this lack of support for PKIs is a serious 
impediment to the roll out ofPKIs, Indeed, the US Federal PKl pilot reported 
that the lack of a fully functional inter-operating X.500 directory was one of 
the inhibitors of PKI rollout [12]. Similarly, the final report [13] of the 
recently completed EC PKl Challenge project (see http://www.cema.org/pki- 
challcnge) states that PKIs arc being held back by the lack of support for 
them in related technologies such as LDAP/X,500 directories and S/MIME 
clients. Consequently, the authors set out to rectify the primary deficiency in 
LDAP. i.e. its inability to Search for X.509 related attributes, by firstly 
defining a standard LDAP schema for the X.509 attributes, and secondly 
implementing this schema and its associated matching rules in the 
OpenLDAP product (sec http://www.opcnldap.org). The schema will allow 
LDAP servers to know the structure and contents of the X.509 attributes, and 
will allow assertion values in Search filters to identify specific fields in the 
attributes. This paper describes the results of this research. 
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1.1 String Matching 

The first approach was to follow the traditional LDAP route. This takes 
the existing X.500 matching rules and defines how all the ASN.l type fields 
of the X.509 attribute value assertions can be carried as ASCII strings in the 
LDAP protocol [14]. For example, the nolBcforc Validity time of a PKC 
might be transferred in a certificate asserdon value as yyyymmddhhmmssZ, 
and might follow the third $ separator character (where preceding S 
separated strings might hold the certificate serial number, the issuer’s name, 
and the subject key identifier). Where there is a CHOICE in the equivalent 
ASN.l type, for example as in the GcncralNames construct, keywords are 
defined and these precede the value, so that it is obvious which option has 
been chosen, e.g. dns myorg.com or ip 123.4.5,6, An extension to the LDAP 
standard schema would define which ASN.l type fields of assertion values 
are to be encoded for transmission in the LDAP protocol (part of the 
simplification of LDAP is that not every field in the DAP assertion need be 
transferred). The individual ASN.l fields of an X.509 attribute value 
assertion can then be passed as ASCII strings in matching rule assertion 
values in the LDAP protocol, by LDAP clients wishing to search for X.509 
attributes containing particular field values. 

When an X.509 attribute e.g, a PKC, is passed to an LDAP server, it 
should parse the attribute, pull out the individual ASN.l values, and store 
these in its indexes, in the same way that it might store and index email 
address attribute values. The LDAP server will need to have a lookup table, 
or equivalent, that knows the X.509 matching rules and the order of 
occurrence of each field in the assertion values presented by the user, so that 
it can compare them to the correct indexes that it is storing. 

Whilst this approach is relatively easy to understand, and follows the 
traditional LDAP method, it lacks the ability to automatically cater for new 
ASN.l type fields, new certificate extensions and new matching rules. The 
problem is that the string encoding of each field in the assertion values, and 
any new keywords, arc specific to each X.509 syntax. As new X.509 
attributes, and new certificate and CRL extensions are defined along with 
their new matching rules, new LDAP string encodings (and possibly new 
keywords) will need to be defined for each new assertion value. 
Consequently new Internet standards will need to be written (or existing ones 
updated) each time this happens. It would be better if a more automated 
approach could be defined. 
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2. COMPONENT MATCHING 

An improvement on the original approach was first suggested by Legg. 
who produced an Internet Draft called Component Matching [15], This took 
a more fundamental approach to the problem. Instead of defining LDAP 
string encodings for complex ASN.l types, it defined UTF8 string encodings 
at the lowest level of ASN.l granularity • the built-in types. Thus string 
encodings were defined for each ASN.l built-in type such as INTEGER, 
BOOLEAN, OCTET STRING, SEQUENCE, CHOICE etc. The encoding of 
more complex ASN.l types would then be built up automatically from their 
component parts. (This part of the document was subsequently released as a 
separate Internet Draft called the Generic String Encoding Rules for ASN.l 
Types, and this is now a standards track RFC [16j,) Lcgg also defined how 
string assertions could be specified about the components of ASN.l values, 
through a ComponentAssertion construct. This defines how each component 
can be referenced, as well as specifying the assertion value and the matching 
rule to be used when performing the comparison. Referencing components 
can be via an identifier, or by its position, for example, a user can assert if 
the value in a SEQUENCE OF INTEGER is greater than or equal to some 
assertion value. 
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Working wiih Legg, we produced two Inicrnci Drafts, one for public key 
certificates [17], the other for attribute certificates [21], describing how the 
generic string encoding rules can be applied to the assertion values for the 
X.509 attribute matching rules defined in [14], We then started to implement 
this using the open source code ofOpcnLDAP. 

This implementation proved difficult for a number of reasons. Firstly it 
meant that all existing LDAP clients would need to be modified to support 
LDAP extensible matching rules, and the generic string encoding rules, so 
that individual components within an X.509 attribute could be specified by 
the client and passed to the server. Secondly all existing servers would need 
to be modified to support the new matching rules, and the generic string 
encoding rules for assertion values. The matching process is complex. 
Incoming X.509 attributes have to be parsed, their individual fields have to 
be located within the DER' byte stream, and pointers to the bytes stored in 
the indexes of the LDAP database, along with their corresponding keywords 
taken from the definition of their assertion values. When a client sends an 
assertion value (as an ASCII string), the server has to match the presented 
keyword against the correct index, then use the associated pointer to pull the 
value out of the ASN, 1 DER byte stream, covert it into an ASCII string, and 
then compare this with the presented ASCII value using the appropriate 
matching rule (c.g. equality match or substring match). This continual 
conversion from ASCII strings to DER bytes and back again is not very 
efficient, but is unavoidable since LDAP is based on ASCII strings and 
X.509 attributes are based on DER bytes. 



3. ATTRIBUTE EXTRACTION 

Other researehers in Germany were also working on the same problem of 
how to seareh for X,509 attributes in LDAP directories. Klasen and Gietz 
were dubious about the approach of Chadwick and Legg. Although it was 
elegant and easily extensible, they did not believe that all the LDAP 
suppliers would implement this mechanism in their products. In fact Legg 
had already implemented component matching in the LDAP server product 
of his company whilst the Internet Draft was being refined. But this had been 
made mueh easier by the fact that their back end database was based on 
X,500 rather than on LDAP, so every field of every attribute was stored and 
processed in its DER format by the database. This meant that no conversion 
had to take place when the server received X,509 attributes for storage, and 



' DER (the Distinguished Encoding Rules) is a subset of BER 




210 



DATA ANDAPPUCATIONS SECUR/TYXV/I 



when clients prcscnicd LDAP siring assertion values, these were converted 
in their DER equivalents, and passed to Ihc back end database. 
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Figure 2. Atlribuie Exiraclion 

Klasen and Gielz proposed an allernative solution, based on the work- 
around that PKI administrators arc taking today. This is lo extract a field 
from an X.509 attribute and store it as a simple, searchable atlribuie. in the 
same entry in Ihc LDAP database. For example, in order lo support S/MIME, 
the PKI administrator cxiracis Ihc user's email address from the Subject Alt 
Name field of Ihe public key cerlificale, and stores this in an email address 
attribute in Ihc user's LDAP entry. The sending user then searches Ihe LDAP 
directory for the needed email address, and asks the LDAP server lo return 
the public key certificate attribute from Ihc entry matching the email address. 
The assumption is that no-one will have tampered with Ihe LDAP directory, 
and that the email address attribute and the subject alt name field in the 
certificate will be identical, 

Klascn and Gietz extended this model, by defining a set of -30 attributes 
for public key certificates, where each attribute holds a field from a public 
key ccrtificalc [18). For example, the x509kcyUsagc attribute holds Ihc key 
usage field, whilst the x509aulhorilyKeyIdcnlifier attribute holds Ihc 
authority key identifier field (this is Ihe identifier of the public key used to 
sign this certiflcale or CRL). If a front end X.509 altribulc Parsing Server 
(XPS) is used lo automatically parse X.509 attributes and extract Ihe fields 
into these attributes, it means lhat existing LDAP servers will not need lo be 
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modified. No new matching rules or assertion values need to be defined, 
since the 30 new attributes use existing matching rules and assertion values. 

The simplicity of this approach is chat most existing (i.e. configurable) 
LDAP clients will not need to be modified either. They can use their existing 
assertion value creation code, and simply need to be configured with new 
attribute types to be used with it. 

We decided to alter our modifications to OpenLDAP by adopting Klasen 
and Gietz’s approach. We added XPS functionality to OpenLDAP, so that 
OpenLDAP can act as either a stand alone XPS server, or a combined XPS 
and LDAP server. We also wrote two new Internet Drafts to compUmeni 
(18], one that defines new LDAP attributes for CRLs (19]. the other for 
attribute certificates [20]. 



4. XPS IMPLEMENTATION 

4.1 The DIT Design 

The conventional X,5()0 design is that X.509 certificates are typically 
held in the entry of the user, as a multi-valued userCertificate attribute, 
holding for example a certificate for digital signature verification, and a 
certificate for encryption. In the XPS design, each certificate is held in a 
separate subordinate entry of the existing user’s entry. This certificate entry 
holds the set of attributes defined in [18] for public key certificates or in [20] 
for attribute certificates, along with the complete unmodified certificate. In 
addition, the XPS server has a configuration option that allows the 
certificates to be still held in the user’s entry as a multi-valued attribute. This 
is useful for example if a client wishes to retrieve all the attributes of a 
particular user. The subordinate entries allow LDAP clients to search for 
fields of the certificate, by using the corresponding attributes and their 
assertion values. When the attribute(s) is(are) matched, the corresponding 
certificate in the same entry can be retrieved. The subordinate entries can be 
named in one of three ways, by using: 

a) a combination of the certificate serial number and issuer name (which are 
guaranteed to be unique), as a multi-valued RDN, or 

b) the certificate serial number and issuer name concatenated into a single 
string (to be used by those LDAP servers e,g. MS Active Directory) that 
do not support the standard LDAP feature of multi-valued RDNs. or 

c) the serial number on its own (this is only suitable for LDAP servers that 
will only ever store certificates from a single CA) 
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The OpenLDAP XPS server has a configuration option allowing the 
administrator to choose the naming scheme most suitable for him. 

CRLs are stored in a slightly different way to certificates. They are 
typically either stored in the CA's entry, or in any entry that is pointed to by 
the CRL Distribution Point extension in a certificate. When using the XPS 
server, each CRL is stored in a subordinate entry of the previous entry, but 
this time each CRL may create a subtree of entries. The immediately 
subordinate entry holds all the attributes defined in [19], except for the 
revocation time and CRL entry extensions (such as revocation reason). The 
latter are stored in subordinate entries of the former, there being one 
subordinate entry per revoked certificate. The reason that a subtree of entries 
had to be created, rather than a single subordinate entry, is that LDAP 
attributes arc a set of values, rather than a sequence of values. Therefore it is 
not possible to relate multi-valued attributes together in any meaningful way. 
Since each revoked certificate has its own revocation time and set of 
extensions, it would not make sense to store a set of revocation times and 
revoked certificate serial numbers in two separate attributes of the same 
(subordinate) entry, and expect a client to be able to determine which 
certificate was revoked at which time. By placing each revoked certificate in 
a separate child entry, it is possible to search for certificates revoked at a 
certain time, or with a certain revocation reason etc. 

4.2 Configuration Options 

OpenLDAP has been modified so that it can be an X.509 attribute Parsing 
Server (XPS) and operate in either standalone mode, or as a front end to an 
existing LDAP server. Those sites that arc already using OpenLDAP as their 
LDAP server, will typically operate in standalone mode, by upgrading to the 
appropriate OpenLDAP release. Those sites that use any other make of 
LDAP server, can simply place the OpenLDAP XPS server as a front end to 
their existing LDAP server as in Figure 2. The Certification Authority is then 
configured to talk to XPS rather than its existing LDAP server, XPS parses 
the incoming request, modifies it, and passes the resulting requests to the 
existing LDAP server. 

The configuration file for the XPS server contains a number of options. 
Administrators can choose which X.509 attribute types are to be trapped and 
have their attributes extracted by XPS, which attributes arc to be extracted 
from them and what these attributes should be named, whether these 
attributes should still be stored in their parent entries as well as the new 
subordinate ones, whether a CRL should be stored as a subtree of entries or 
not, what form of names to be used for the new subordinate entries, and 
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finally where error and writc*ahcad logs should be stored. Write-ahead logs 
are needed because LDAP servers do not support transaetions, therefore the 
XPS server has to store its set of intended updates in a WAL before actually 
applying them to the LDAP server. This will allow XPS to rollback the 
LDAP server should an error occur midway through the set of updates. 



5. DISCUSSION AND CONCLUSION 

The component matching approach is a more elegant solution, since the 
X.509 attributes are only stored once in the LDAP directory, and matching is 
performed directly on their contents. Attribute extraction on the other hand, 
doubles or trebles the storage requirements of the LDAP server, and 
matching is performed on the attributes associated with the X.509 attribute, 
rather than on the X.509 attribute itself. It would therefore be possible, 
especially if the LDAP server was hacked, for the attributes to no longer 
accurately reflect the contents of the associated X.509 attribute. 

However, attribute extraction is somewhat easier to implement than 
component matching, especially on the client side. Furthermore, by using a 
stand alone XPS server, existing LDAP servers do not need to be modified. 
Given the past reluctance of LDAP vendors for more than 5 years to solve 
the problem of searching for PKI related attributes, we have some doubts if 
they arc likely to implement component matching anytime soon. We 
therefore conclude that attribute extraction is the best pragmatic solution to 
quickly solving the current problem of PKI users who need to search for 
X.509 attributes in an LDAP directory. 
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Absiracl In ihe currciu public *kcy infrasimciure {PK1> sdiemes basal on X.S09, a 
relying parly miisi validate a U5;er's certificate a& well as the exUtence ofa path 
from il& trust points to the CA of the certificate. The latter pan is referred to as 
certificate path validation. In this paper, we suggest an efficient certificate path 
validation scheme (ECPV) that employs delegation with efficient computing at 
relying parties. In particular, in our scheme, a relying party is provided with 
certificate path validation trees (CPVT.s) depending on its trust p<>inLs and 
applicable trust policies. This information should enable a relying party to 
perform certificate path validation locally. The CPVAs can be deployed either 
as autonomous entities or in a federated mode. We discuss the two major 
components of ECPV: the data harvester and the data analyzer. Some of the 
concerns of security, trust, and performance are also discussed. 



Keywords: Certificate Path Validation Authority (CPVA), certificate path validation trees 

(CPVT), delegated path discovery (DPD). delegated path validation (DPV), 
public*key Infrastructure (PKl), security and trust 



1. INTRODUCTION 

Digital certificates have emerged as a popular tool to provide 
authentication, privacy, integrity, non-rcpudiaiion and other security 
requirements in modern day transactions [1|. PKl provides a comprehensive 
infrastructure for issuing and managing public keys in the form of digital 
certificates to a set of users [1.10], When two users want to communicate 
with one another in a secure manner, they will have to authenticate each 
other prior to the actual communication. This slrangcr-to-slrangcr 
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communicalion is made possible by having a trusted Ihird-parly (TTP) in the 
form of Ccrlificalion Aulhorily (CA) whom both the parties irusl. When a 
user or subject submits a certificate to a relying parly (RP) for a service, ihe 
relying party would like to validate the user certificate prior to offering a 
service. 

Typically, the validation of a certificate is done in three steps. In ihc first 
step, a relying party (RP) builds a chain of trust, also known as certificate 
chain, starting from the CA that has issued ihc user’s certificate lo the CA 
that RP trusts (also known as a trust point). This step is known as certificate 
path discovery. Generally, trust between CAs is established by issuing CA- 
CA cross -certificates. These certificates can also be revoked from time to 
lime. Thus there is a need to confirm the validity of the links in the certificate 
chain built in step one. The second step conducts the validation, and is 
referred to as certificate path validation. (The logic for the validation process 
described above is described in RFC 2459 [9.10] and is based on various 
parameters specified in certificate policies.) In the third step, the validity of 
the issued certificate is itself verified with information provided by its CA. In 
this paper, we are interested in the first two steps of the validation process. 

Recent research trends in public-key infrastructure favor delegation of 
authority for ccrlificale path validation to trusted-severs and for path 
discovery to untrusted- servers. DPV (Delegated Path Validation) and DPD 
(Delegated Path Discovery) are examples of such protocols [9], These 
protocols are still evolving and are described in Internet drafts [8.9], Simple 
Certificate Validation Protocol (SCVP) is another delegation protocol that is 
conceptually similar to DPV and DPD [6]. 

In this paper, we propose an efficient certificate path validation (ECPV) 
scheme lo overcome the weaknesses in the current path validation protocols. 
Our scheme is based on one or more certificate path validation authorities 
(CPVA) that upload RPs with a certificate path validation trees (CPVT). An 
RP, in turn, can use this locally available tree to validate certificate paths of 
user certificates. The trees shall be periodically updated by the CPVA. The 
CPVAs can be implemented either as an autonomous entity working in 
isolation or organized as a federation to share information. 

The paper is organized as follows. In section 2. we discuss some of the 
issues in certificate path validation and current solutions. In section 3, we 
describe the proposed ECPV scheme for certificate path validation, A more 
detailed description of the CPVA module is provided in section 4. Two 
possible options for deployment are discussed in section 5. Section 6 reviews 
the security, trust, and performance aspects of the proposed scheme. Finally, 
section 7 summarizes the contributions of the paper and discusses plans for 
future work. 
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2. ISSUES IN CERTIFICATE PATH VALIDATION 

As explained in section 1, certificate path validation involves the task of 
discovering a path and then verifying its validity. The path discovery is both 
compulation and communication intensive, since it involves discovering a 
network of CAs that trust each other. Several factors contribute to the 
complexity. First, there are many possible trust topologies (5,8,9.11). Strict 
hierarchical, multi-rooied hierarchical, mesh, bilateral cross-eertification, and 
bridge topologies are a few example topologies. However, many of the 
present RP implemeniaiions make simple assumptions about the trust 
structure and are not capable of handling these complex trust relationships 
1 11,14], Changes in the trust hierarchies over time also nceessiiate changes in 
the relying parly software, an impractical proposition. 

Second is the trust policy issue. Each RP has an aceepiable trust policy 
for the chain of CAs that it is trying to validate for a given certificate [3]. The 
policy would describe the minimum level of CA practices that it cxpeeis 
from each of ihc CAs on the path. Similarly, each CA also specifies, in its 
CA“CA certificate, the practices (policies) that it trusts other CAs to follow 
[1.2], As a consequence of a wide variety of such policies, the task of RP 
becomes more complex during path discovery since it should only select 
those links that are compatible with its (RP’s) own policy. Cheeking the 
policy compatibility is not a simple process (2,7,9), 

Third, response time is also one of issues for certificate path validation. 
For example, an RP is very much interested in responding to its users as soon 
as possible with the service they requested. However, it cannot do so until 
the path validation and the subsequent certificate validation arc complete. 

Fourth, CA and repository availability is also an important concern to an 
RP. All of the CAs and the relevant certificate and revocation information 
repositories need to be available for an RP to discover and validate a path. If 
a trust path is long, with several CAs, there could be a problem in data 
collection as some entities along the path may not be accessible during 
validation [9,11.14]. In other words, even though a CA-CA certificate is 
valid, due to the inability to access a CA’s data at the validation time, an RP 
may not be able to validate a certificate. 

Finally. RP is concerned about the cost of validation. It would like to 
minimize this cost. When each RP undertakes the task of discovery and 
validation (i,e., if it is not delegated to a server), it is an expensive process. 
Substantial cost savings may nol be realized if the entire process of 
validation is repeated for each certificate that the RP receives, even when 
delegated to a trusted validation server. 
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From Ihc above discussion, it is clear that certificate validation is a 
complex process involving considerable amount of communication and 
computational resources. 



3. ECPV: PROPOSED SCHEME FOR CERTIFICATE 
PATH VALIDATION 

ECPV is based on the idea that it is much more efficient to provide a 
relying paity with path validation information in the form of trees (CPVT) 
rather than to require the RP to request an external server for each certificate 
validation. Section 3.1 describes the CPVTs in greater detail. 

3.1 Certificate Path Validation Trees (CPVT) 

To explain the concept of CPVT, let us consider the example in Figure 1. 
Figure 1 (a) describes a set of trust relationships between a set of CAs (CAl • 
CA9). Here, an arrow between one CA and the other (e,g.. from CAl to 
CA5) indicates that one CA has issued a cross-CA certificate to the other 
(e,g., CAl issued a certificate to CAS). The arrow type indicates the 
similarity between the trust parameters, which could be established by policy 
mappings (e.g., CAl policy OID» maps to policy OIDy for CAS). 

Suppose a relying party RPl trusts CAl. In addition, it accepts input 
parameter set 1 for some type of requests and input parameter set 3 for other 
types of user requests. In this ease, the intent is to build two trees for RPl 
with CAl as the root, one with IP set 1 and the other with IP set 3. Figures 
( lb) and (Ic) arc the required trees derived from Figure la. These are what 
we refer to as certificate path validation trees or CPVTs. For RPl to accept a 
certificate issued by CAx under IP set 1, for example, it expects a path from 
CAl to that CAx in the CPVT in Figure (lb). In this case, for example, only 
CAl. CA3. CA7, and CA9 meet the criteria. In fact, each directional edge in 
Figure 1 is associated with an expiration time (not shown in the figure), 
derived from the expiration time of the cross-CA certificate and the CRL (or 
ARL) issued by the parent CA. Thus, an edge in the network or CPVT is 
valid only if it has not expired at the time of its usage. The advantages of 
building the path from trust point, commonly refened to as building in 
reverse direction, are very well discussed in [7). 




ECPV in Public-Key Infrastructure 



219 





►► ITKkI > IPSetl ^ n*Se«3 

IP; Piirszn«i«rt for CtnlAcoi* VUidotion 

Figure I. Illusu-adon of Certificate Path Validation Trees (CPVT) 



3.2 System architecture 

The system architecture for ECPV is shown in Figure 2, The various 

components of the system arc as follows: 

( 1) CA Module: The certification authority (CA). its registration authority 
(RA), the repository (REP), and OCSP responder together represent the 
CA module. 

(2) CPVA module: The CPVA (Certificate Path Validation Authority) is the 
critical module that will perform the process of path discovery and 
verification. This module consists of harvester (HRV) and analyzer. 
CPVA is responsible for building the CPVTs and distributing them to the 
RP modules, 

(3) RP module: The relying parties (RP) service the requests from subjects 
for certificate validation. The relying parties provide requisite 
information, including trust points and validation policies, to the CPVA 
module, which builds relevant CPVTs based on the input and download 
CPVTS to the RPs. RPs arc the primary users of the infrastructure for 
validation of certificates. 

(4) Subject module: Subjects or clients request service from the RPs and 
offer their certificates for validation. The subject’s influence the system 
design and performance from their diversity and rate of requests. 
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Figure 2. Sysiem Archilcciure 

Another important aspect of our archiieciurc is the interactions ajnong the 
modules. Among all interactions in our system, the following three arc 
relevant with respect to this paper: (i) the RP*CPVA interactions, (ii) CPVA- 
CA interactions, and (iii) CPVA-CPVA interactions. We summarize these 
three types of interactions in the form of scenario-like description of events 
starting from an RP submitting a request to the uploading ofCPVTs to it. 

1, Each relying party (RP) submits a set of input parameters with vital 
information like trust point CAs, policy constraints, name constraints, 
maximum path length, etc. 

2. The CPVA consolidates the RP information and requests its harvester 

component to collect data a set of <trust point, input parameter set> 
pairs. 

3. Harvester collects all the requisite information including CA certificates, 
CRLs, OeSP responses, etc, (In the federated scheme, a harvester may 
also collect CPVTs from other CPVAs), 

4. The analyzer analyzes the collected data, and builds CPVTs based on the 
RPs' requests initially received. The analysis includes looking into the 
CRLs (also refened to as ARLs [1,10]) and the OCSP responses for 
validity of CA certificates. In addition, it needs to take a note of the 
validity of each response — how long is a published CRL applicable. 
Using this information, it builds CPVTs with trust points as the roots. 

5, The CPVA uploads the appropriate trees to the respective RPs (i.e., each 
RP gets only the relevant CPVTs). 

6, Since some edges of a CPVT may expire after the initial upload, the trees 
automatically get pruned at the RP while being used for certificate 
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verification. In addition, the CPVA also keeps track of the expirations 
and updates its trees with periodic data. The updated trees may be either 
automatically uploaded (in a push scheme) or requested by a RP (in a 
pull scheme). 



4. THE CERTIFICATE PATH VALIDATION 

AUTHORITY (CPVA ) 

As shown in Figure 2. CPVA has two components: harvester and 
analyzer. While the claimed simplicity of RP software comes from the 
harvester’s functionality, the benefits in performance arc due to both the 
components. We now describe these components. 

4.1 The harvester 

The concept of harvester is adopted from the concept of data harvesting 
in digital libraries [14]. A harvester traverses the CA repositories and OCSP 
responders and collects all the requisite information like certificates. CRLs. 
and OCSP responses. 

The repositories use multiple directory protocols like DAP. LDAP. FTP 
and HTTP, and also have directory chaining, directory referrals. This 
necessitates the harvester software to be complex and capable of 
communicating with different protocols. The components of the harvester, as 
follows: 

• Bulk Harvester: The bulk harvester is activated for gathering of 
information at initialization as well as occasionally to refresh data, 

• Incremental Harvester: The incremental harvester is executed 
frequently to keep the data current. It can be activated on events like 
certificate expiry, CRL expiry, addition of new CAs. etc. 

• The Scheduler: Tlic Scheduler components triggers the incremental 
harvester and the bulk harvester at appropriate times to keep the data 
up-to*date. 

• Data Normalizer: Since the collected data during the harvesting can 
be in different formats, the data normalizer reformats the data into 
single format for easy processing by the data analyzer module, 

4.2 The analyzer 

Once the harvester has obtained all the relevant information, it is the 
responsibility of the analyzer to construct the CPVTs to upload to the relying 
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parties. In addition, the analyzer is responsible for detecting any changes in 
the current CPVTs that it may have previously uploaded to RPs. For 
example, in a push model where the CPVA is responsible for updating the 
CPVTs at the RPs, the data analyzer should be able to upload the changes (or 
the new CPVTs) to the affected RPs. Since data analyzer is mainly 
responsible for constructing the CPVTs for the relying parties, the next task 
is to generate CPVTs from the mesh. There are several options in building 
the trees. 

The analyzer has the following four components. 

• The Client Processor: The Client processor consolidates the data 
received from the various RPs that the CPVA serves. 

• The CPVT Builder: The builder performs the primary action of 
building the CPVTs based on the information obtained from the 
Harvester and other CPVAs. The Builder builds the trees for different 
trust points according to particular input parameter set. 

• Han>esier Coordinator: This component interacts with the harvester 
to specify the information that the harvester needs to collect and feed 
the Scheduler with appropriate times for re-harvesting the data. 

• Federation Coordinator: As shall be discussed in section 5, the 
CPVA scheme can be deployed in autonomous mode or in a 
federated mode. When the federated model is used, the data analyzer 
will collect CPVTs from other CPVAs and use them to build the 
CPVTs. 

5. DEPLOYMENT OPTIONS WITH ECPV 

The ECPV scheme with CPVAs as primary components can be deployed 
in at least two ways: autonomous and federated. In the autonomous mode, 
the CPVA shall work in isolation to collect the data, to build the CPVTs, and 
serve only its clients. Certainly, this scheme is not highly scalable and docs 
not offer high performance benefits in information processing. These 
disadvantages can be overcome by the federated mode of deployment where 
CPVAs would coordinate with another to build and to maintain the CPVTs in 
a highly scalable and distributed manner. 

5.1 Autonomous harvesting 

When RPs handle certificates from a few domains, and the number of 
CAs are limited, autonomous harvesting works very well. In this method, 
each CPVA module is independent (of other CPVAs), Its harvester is 
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responsible for contacting the individual CAs/OCSP rcspondcrs/dircclory 
repositories to obtain the needed certificates, revocation lists, and certificate 
status responses, CPVA module is responsible for several RP’s (say in its 
domain). It is responsible for harvesting data from CAs related to requests 
from its RPs. 

5.2 Federated harvesting 

Once PKI technology becomes popular among the internet users, there 
would be thousands of CAs issuing certificates for their own specific 
domains. In other words, unlike a handful of CAs we currently have (e.g., 
Verisign, Entrust, etc.), there would be several autonomous ones issuing and 
managing certificates. !n such an environment, it would not be possible for a 
single harvester to obtain information about all CAs, their CRLs, and the 
trust paths connecting them. 



6. SECURITY, TRUST, AND PERFORMANCE 
ISSUES 

As stated already, the primary impetus for our work is two-fold: to 
simplify the task of relying parties by delegating some of the data collection 
and processing work to CPVAs; and to arrive at a scheme that is efficient and 
scalable. These objectives arc to be achieved without compromising the 
security and trust offered by the traditional certificate path validation 
schemes. In this section, we briefly discuss our scheme in the context of 
security, trust and performance. 



6.1 Security and Trust Aspects of ECPV schemes 

One of the primary concerns of a relying party in adopting the ECPV for 
path discovery and validation is of trust. In other words, why should a 
relying party trust that the information provided by CPVA is correct? This 
concern exists even with the current delegated path discovery and validation 
protocols [8.9]. But let us look at our schemes. 

Under autonomous deployment, where the CPVA collects all the needed 
information (e,g„ CRLs, expiration times, OCSP responses, etc,) by itself 
and prepares customized CPVTs for each relying party, the solution is 
simple, A CPVA signs the provided CPVT. Thus, there is a guarantee that an 
impostor process has not supplied incorrect results. This also ensures non- 
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repudiation. In fact, to encourage more RPs to use its service, a CPVA may 
offer some kind of a guarantee as is done by Digital Signature Trust 
(http://www.digsigtrust,eom) in the case ofpublic-key certificates. 

In addition, optionally, it provides all the information used to arrive at the 
CPVT, Since the information is itself signed by the providing entities (e.g,. a 
CA digitally signs the CRL that it issues, and an OCSP responder signs its 
response), the evidence is self-explanatory and is trusted. 

Under federated deployment, a CPVA that provides the CPVT to a 
relying party is not necessarily the one that directly contacted the 
corresponding CAs. Instead, it may have received either the raw information 
or part of the trees from other CPVAs. So it appears that the trust is 
somewhat weakened. However, if each CPVA signs its response (e.g., partial 
trees) or simply forwards the CA signed raw information to its requester, 
then the concern is mitigated. For exajnple. if each CPVA, when it receives a 
signed partial CPVT from another CPVA, checks the signature, prepares a 
new CPVT (if it merged several partial CPVTs into one), and digitally signs 
it, then there would be no problem of trust. The idea of providing guarantees 
(as in Digital Signature Trust discussed above) by each CPVA further 
enhances the trust aspects of using the CPVA servers. If the RP does not trust 
the CPVA. it can receive all the supporting data along with the CPVT and 
verify, this process is considerably faster than RP having to perform the path 
discovery process all by itself. 

6.2 Performance aspects of CPVA schemes 

Let us consider CPVA and its impact on the relying parties. Clearly, a 
relying party is simplified due to the delegation of data collection and path 
construction to CPVA. This is sitnilar to SCVP and DPD/DPV [8.9]. But 
CPVA significantly differs from other schemes in the information it provides 
to the RPs, While other schemes only provide the status information 
(yes/no/error/don't know) to an RP’s request, CPVA empowers a relying 
party with validation trees that could be used by the RP to locally verify 
users' certificates. In other words, the response time, or latency, of an RP is 
greatly improved due to CPVA. In addition, by providing policy-specific 
CPVTs. an RP is able handle requests with varied values. For example, if a 
request is for a low-value service, it could use a CPVT of a weaker trust 
assurance. On the other hand, for a high valued transaction it could use a 
CPVT with a strong trust assurance. In summary, by caching the CPVTs. the 
performance of the RPs is greatly improved. In addition, the CPVA can 
handle much larger number of RPs since it receives requests from RPs less 
frequently. 
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Now let us look at the comparison between autonomous and federated 
schemes. Clearly, the load on CPVA is much larger in the autonomous 
scheme since its harvester is responsible for directly collecting data from all 
the required CAs. On the other hand, in federated mode, the load is 
distributed among several CPVAs, However, in this scheme, since the same 
request (and hence data) flows through several CPVAs. there is higher 
communication and processing overhead on the network and the intermediate 
CPVAs. But this scheme is highly scalable and has better performance than 
autonomous mode. 

Both schemes can greatly benefit from caching at the RPs and at the 
CPVAs. Since CA’s certificates often have longer life and are less likely to 
be revoked, the CPVTs tend to have much longer validity periods. This 
means that a CPVT once uploaded to an RP can be used for quite some time 
to validate subject’s certificate paths. In addition, the incremental approach 
of updating the trees along with the push/pull methods used to distribute the 
changes greatly enhances the performance of the RPs as well as the overall 
system. 



6.2. 1 Costs and benefits 

The performance of CPVA can best be quantified in terms of its costs and 
benefits when compared to traditional validation schemes. 

The following benefits are claimed performance advantages of CPVA 
over traditional schemes: 

• Improved response time at RPs due to reduced time for 
certificate path validation. This implies that RP's response to 
user’s service requests is improved. 

• Improved system availability at RPs due to localized certificate 
path validation. This implies that the user requests are much more 
likely to be validated and serviced. 

• Reduction in overall communication cost in the system due to 
harvesting at CPVA. This is due to the harvesting ofCA and cross- 
CA certificate data ahead of time and using this information to 
supply validation trees to the RPs, 

However, these benefits arc accrued at the following costs. 

• Cost of harvesting. The harvester may collect more (bulk) 
information than needed. In addition, it needs to collect data to keep 
CPVA's validation trees up-to-date. 
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• Cost of analysis. The analyzer needs to analyze harvcsic<l data and 
build trees some of which may never be needed. 

In summary, while the RPs benefit by receiving the validation trees for 
local certificate path validations, the system of CPVAs place additional 
communication and computing overhead on the system. In this section, we 
provide aback-of-thc-cnvelope analysis to quantify the costs and benefits. 

6.2.2 Key Parameters influencing CPVA Performance 

While several parameters influence the performance of the proposed 
scheme, the following three parameters arc the key factors. 

• Validiiy period and revocation ofCA-CA certificates: Each CA-cross 
certificate is valid for certain period of time. Unless its issuing CA 
revokes it, a cross certificate is valid until the specified expiration 
time. Whenever such a certificate expires or has been revoked, it 
results in the following costs for the CPVA: 

o Communication cost for the harvester to collect information 
to update the validation data, 

o Computation cost to select and rebuild the affected 
validation trees (if any). 

o Communication cost to send updated trees to the affected 
RPs 

• Rate of validation requests: Rate of validation requests of RPs 
determines how effectively the validation trees are being used by the 
RPs. For example, when the rate of requests is high, it implies that 
the savings due to local validation trees at RPs is high, and. hence, it 
may offset the cost of building, maintaining, and uploading of these 
trees to RPs. 

• Maximum (trust) path length and topology: Wider adoption of PKI 
will necessitate greater number of CAs, probably with complex CA- 
CA trust relationships. For medium to low security applications, 
larger (5-10) values for the maximum path length can be adopted to 
facilitate wider acceptance of certificates. 
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1 . CONCLUSIONS AND FUTURE WORK 

In this paper, we proposed an efficient certificate path validation scheme. 
In our scheme, a relying party receives a cerlificale path validation tree 
(CPVT) from the delegated server (CPVA). The tree is stored locally at the 
relying party. A relying party can now validate the path locally. The 
delegated server consists of a data harvester and a data analyzer. We 
proposed some implementation schemes for both these eomponents. The 
local caching ofCPVTs greatly reduces the overhead due to delegated server. 
At the same time, since a relying party is not responsible for collecting data 
from different CAs and OCSP responders on the internet, its software can 
still be simple. We have suggested several options for implementing the data 
harvester and the data analyzer. We have also shown that our scheme does 
not weaken the security and trust properties of delegation. 

We arc cuncntly looking into further design options for implementing the 
CPVA. One of our objeetives is to improve the efficiency of harvester and 
analyzer. We are also looking into extending the representadon structures 
from trees (CPVT) to other data structures. 
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Abstract Web services security is becoming a criiicaJ concern for any organi* 
zaiion adopting (he XML-based Web services approach lo application 
integration. While many access control techniques for Web services are 
becoming available, severaJ Issues still need (o be solved in order (o 
correctly split the burden of securing Web services between the perime- 
(ral and (he service level. In this paper, a technique is presented able to 
make perimetral defences semantics*aware. Application-level senumticx- 
aware firewalls tniorct filtering rules directly SOAP messages based 
on the nature of (be services they request. O ur semantics-aware firewalls 
rules are written using a flexible XML*based syntax that allows sharing 
metadata concepts wilh service level access control policies, supporting 
complex security policies that integrate perimetral defences with access 
control. Moreover, (hey can be quickly integrated into organizations' 
existing infrastructure, deployed rapidly and scaled as needed. Also, 
they integrate easily with existing infrastructure and can be operated 
by current staff, potentially achieving a low total cost of ownership with 
respect to service level solutions. 



1. Introduction 

ll is widely acknowledged that open standards such as XML [3] and 
HTTP [9] offer reduced integration cost, boosting the potential for in- 
creasing organizations' capability to compete and succeed in today’s 
global c-market. A well established trend toward a Web-centric scenario 
for both uscr-to-application and application-to-application interactions 
exploits Web services' flexibility, expressivity and standardization. As 



'The lertn Web services describes Web af^licaiion componenis build upon existing and 
emerging technology standards including XML, SOAP, WSDL and HTTP. 
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far as protocols are concerned, Web services growing success hints to 
a scenario where HTTP, with its secure variant HTTPS, is the only 
general-purpose application protocol used for a variety of services. The 
benefits of this evolution arc dear: 

■ A simplified and homogeneous level 7 of the ISO/OSI stack with 
a single reference application protocol, i.e. HTTP, together with 
a standard remote method invocation technique, i.e. SOAP [2], 
overcomes the usual difficulties in integrating specialized services 
and proprietary platforjns; 

• a standard data interchange format, i.e. XML, makes integration 
of functions offered by heterogeneous systems much easier than it 
was in the past. 

There is an additional claimed benefit of the Web-centric model, which 
has perhaps more to do with business than with technical reasons: tun- 
nelling remote jncthod invocations through HTTP connections, serves 
the goal of so]wing firewall traversal problems caused by the attitude of 
system administrators, and actually of most network security best prac- 
tices. of blocking most application protocols at the corporate network 
perimeter. As a matter of fact. Web services firewall traversal capabili- 
ties introduce significant security risks, encouraging companies to selec- 
tively expose pieces of their enterprise applications. While a number of 
access control techniques for Web services arc becoming available [7. 1). 
many researchers agree that the temptation to deal with Web services’ 
security by access control alone should be resisted, because a number of 
security and operating issues arc more effectively solved at perimetral 
level. In order to check SOAP traffic crossing organizations' perime- 
ters, however, firewalls should become semantics- aware, at least to a 
degree. Commercial SOAP proxies are becoming available capable of 
performing sophisticated filtering of SOAP payload (to name but a few, 
Reactivity XML firewall, http: //www.r eactivity.com. and Quadra- 
sis/Xtradyne SOAP Content Inspector, http: //v^ww. quadras is .com. 
arc examples of dedicated hardware appliances; Check Point Application 
Intelligence, http: //v^ww, checkpoint. com, instead, is the new SOAP 
proxy feature provided by the last release of market leader Firewall- 
1). However, the debate on their usage and impact is still at a pre- 
liminary stage: while enterprises have quickly come to realize the im- 
portance of securing XML. they arc only beginning to understand the 
many operating issues and the corresponding costs involved in imple- 
menting XML security at the single service and at the perimetral level. 
In this paper, we introduce a new concept in application security, the 
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senuinfics-aware perimeter proxeciion, aimed ai cosl-effeclively sharing 
with service-level access control the heavy protection burden that Web 
services applications require, reducing the risks associated with integrat- 
ing heterogeneous applications that cross organizational boundaries. In 
our approach, semantics-aware firewalls are not just simple filters acting 
on XML payload: rather, they systematically monitor XML-based mes- 
sages between business partners, customers and others, enforcing rules 
written in a highly expressive, XML based language. When it is com- 
putationally feasible, rules enforced by semantics-aware firewalls may 
refer to service properties smoothly integrating with service level access 
control policies. Like our approach to XML and SOAP access control 
[5, 6. 7|. our semantics- aware firewalls cleanly separate Web services se- 
curity from the business logic in each application. This allows adminis- 
trators to independently define and audit muitiple-lcvcl security policies. 
The paper is structured as follows: Section 2 presents some basic con- 
cepts, relevant to our approach, referred to: Web services, the SOAP 
protocol, perimeter protection and network firewalls. Section 3 presents 
our new concepts of semantics-aware perimeter protection. It clarifies 
the context, which problems are tackled, how SOAP headers should be 
customized for perimetral security, and highlights some performance and 
manageability requirements. Section 4 describes how semantic- aware fil- 
tering rules are modelled in our framework, specifies their syntax and 
semantics, and presents a case-study example of semantic-aware policy. 
Section 5 draws our conclusions and sketches our plans for future works. 

2. Basic concepts 

2.1. Web services in a nutshell 

Weh services arc the last evolution of basic Remote Procedure Calls 
(RPCs) and are aimed at providing a new form of distributed computing 
environment for business-to-busincss and business- to- consumer applica- 
tions. Aside implementation differences with respect to RPCs, Web 
services emphasizes the adoption of standard technologies: a standard 
definition mechanism, standard lookup services and standard transport 
definitions. The goal is to make remote systems fully interoperating. 

For the purpose of this paper, we are expecially interested in SOAP [2, 
12]. which is the key technoiogy for carrying out Web services interac- 
tions on the net. In the following we give a brief overview of SOAP 
features that arc relevant within the scope of this paper. In particular, 
we focus on the SOAP HTTP Binding scenario [12], which is represented 
by applications exchanging SOAP messages via HTTP, 
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SOAP is a stalelcss, one-way message exchange paradigm that, if 
combined with features of the underlying application protocol, could 
be used to realize different interaction patterns like: the response mes- 
sage exchange pattern, which is provided by the use of the HTTP GET 
method in a HTTP request to return a SOAP message in the body 
of the HTTP response; the requesi/response pattern, which is the one 
followed by using the HTTP POST method for passing SOAP mes- 
sages in the body of HTTP requests and response messages; and the 
request/muliiple responses, which is not directly supported by HTTP 
but should be implemented at application level |12], We arc interested 
in the request/response exchange message pattern, because cxpccially 
well-suited for RPC -like interaction, as Web services arc. 

The general structure of a SOAP message consists of an XML docu- 
ment composed by an Envelope element that contains two sub-elements: 
an Header and a Body. A SOAP Header contains auxiliary information 
such as directives or contextual information related to the processing 
of the message. SOAP is exensibic in an application-specific manner 
by customizing such auxiliary header's information. Within a SOAP 
Header, sub-clcmcnts calicd Header Blocks represents data logically 
grouped that can be used by intermediaries handling a SOAP message 
between a sender and an ultimate receiver. 

2.2. Perimeter protection concepts 

The goal of perimeter protection is to deploy security measures at the 
perimeter of a corporate network. The perimeter of a corporate network 
is represented by the access points to and from external networks. like 
the network segments connecting the company to the Internet, external 
routers facing the Internet Service Provider's network, dial-in modem 
pools. Virtual Private Networks, or Wireless LANs. 

The underlying assumption that motivates security measures based 
on the notion of corporate's perimeter is that relying on host-based se- 
curity only is not an effective strategy. If interaction between untrusted 
domains and application hosts arc not mediated by any filtering com- 
ponent. then all application servers are exposed to the whole range of 
security threats, either ba.scd on application related features or network 
accesses. Securing and hardening all application servers to be resistant 
to direct Internet attacks has been proven to be extremely hard, too 
complex and expensive to maintain for representing a general solution. 
Here comes pcrimctral defense that uncouples possibly hostile environ- 
ments from data or resources to be protected and inspects interaction 
either at network or application level. 
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Firewalls arc the main and most popular perimeter protection sys- 
tems. A firewall is a system or a group of systems that enforces an a:cess 
control policy on network traffic as it passes through access points [4]. 

Firewalls arc typically classified into three main classes: static packet 
filtering, stateful firewalls, and proxies. 

3. Semantics-aware perimeter protection 

Traversing firewalls is more a management than a technological prob- 
lem, since every firewall technology lets system administrators make the 
screening provided by firewalls completely transparent at will, with re- 
spect to every communication protocol. In other words, every remote 
method invocation protocol could traverse firewalls provided that sys- 
tem administrators configure the pcrimetral policy accordingly. Unfor- 
tunately, many applications and protocols have been proven to be highly 
insecure or simply too complex to be effectively secured. This situation 
has brought most system administrators to prevent some application- 
level traffic from flowing through perimeter defences. From the network 
security’s viewpoint the fact that traversing firewalls is usually severely 
restricted should be regarded as an useful feature and the right attitude 
of a savvy administrator rather than a problem, ^FVom the standpoint 
of application service providers, vendors or developers of Internet appli- 
cation services and corporate managers willing to exploit the business 
possibilities of the Internet, the constraints imposed by firewalls impair 
full exploitation of business opportunities. While one might be tempted 
to remove this impairment by entirely leaving application security to 
service-level access control policies, this choice is likely to prove unwise 
in the long run. Indeed, an inherent danger of the widespread adoption 
of Web services would be neglecting the value of perimeter protection by 
assuming that Internet applications and users will attempt to directly 
interact with Web services, with no intermediate screening and active 
monitoring. This would make the services' interfaces open to exposure: 
if compromised (and all components direcly exposed to Internet connec- 
tions should be considered at high risk), application policies might be 
subverted and critical assets, databases and systems, might be put to 
risk.^ 



towering ihe imporlaiice of perimetral defenc&s policy would leave definidon and man- 
agement of corporate .security to application maiiagers alone, another choice that may prove 
organizationally unwise. 
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3.1. The firewall traversal problem 

The SOAP protocol lets interactive application traffic to be tunnelled 
through regular HTTP eonununications, which makes the usual associ- 
ation between service and application port for TCP and UDP commu- 
nications no longer descriptive of the type of service carried out by a 
certain flow of packets (i.e. all SOAP-based services appear directed to 
servers responding at port 80, the conventional HTTP daemon). The 
net effect of this use of HTTP as a general-purpose application protocol 
for distributed computing is that conventional firewalls, screening net- 
work traffic mostly at level 2 and 3 of the TCP/IP stack, are no longer 
able to efficiently filter out packets. Firewalling SOAP network traffic 
needs content-based inspection capabilities and detailed knowledge of 
Web services and their semantics. 

With SOAP, there is no longer a straight separation between the 
perimetral and the service level with respect to data used for enforc- 
ing security policies. Both must use same data, cither in the SOAP 
header or body, and with similar enforcing mechanisms. This makes 
perimetral and service levels more strictly coupled than in the past and 
calls for a new comprehensive and integrated approach to corporate se- 
curity by developing systems that allow managing a uniform corporate 
security policy and permit to enforce it at both the perimeter and the 
service level, 

3.2. Using SOAP headers for perimeter 
protection policies 

SOAP headers, used to hold metadata as.socialed with the requestor, 
have already been used to carry security credentials. A first proposal 
exploiting SOAP's headers for enforcing access control was presented by 
Damiani et al, [7). The authors represented all the information charac- 
terizing the subject of a request by means of a custom header included 
in each SOAP call. This usage of SOAP's headers has then gained ac- 
ceptance and has been adopted in popular frameworks like the Microsoft 
WS-Security specification [1]. which proposes a set of SOAP extensions 
that can be used to implement integrity and confidentiality in Web ser- 
vices. 

Both (1] and |7| arc based on the assumption that a requestor of a 
service declares the possession of some personal credentials to the server 
providing the requested Web services, which, in turn, authenticate the 
requestor and provide the permissions corresponding to a defined se- 
curity policy. This design choice is coherent with the overall design 
principle of SOAP interactions and security model, where requestor ere- 




Semantics- aware Perimeter Protection 



235 



dcntials. stored in the Header part, arc firstly used to prune an aeecss 
control policy, and then caeh service request is matched at run-time 
against the set of permissions available for the given requestor. How- 
ever, it docs not match two basic requirements of a perimeter protection 
policy, namely: 

■ Filler Granulariiy. There exists a trade-off between communica- 
tion performances and complexity of filtering techniques. Filtering 
operations at the corporate’s perimeter should generally be coarse- 
grained and not requiring complex parsing activity; 

■ Organization-wide Policy Management There exists a clear sepa- 
ration of duties between corporate system administrators and ap- 
plication administrators with respect to the definition and manage- 
ment of access control policies. Attributes to be matched against a 
perimeter protection policy should be corporate- wide and specify 
application clas.scs instead of being related to single services and 
single requestors. 

3.3. Performance and manageability 
requirements 

^Ffom the performance point of view, SOAP-based screening at corpo- 
rate borders could become a severe communication bottle-neck. A list 
of requirements that should be taken into account when dealing with 
performance issues follows: 

m simplicity of screening mechanisms (e,g. string pattern matching 
or simple regular expression matching), with the option of making 
them more complex and refined only at will; 

■ heavy usage of cryptographic mechanisms could easily become the 
dominating factor of processor workloads with consequent degra- 
dation of routing capabilities of network traffic; 

• complex parsing techniques of the SOAP Body and network la- 
tency due to communication with third-parties like Security To- 
ken Services. Authorization engines or Certification Authorities arc 
possibly sources of severe degradadon of performance and routing 
capabilities; 

■ in real-world situations, communication efficiency is one of the 
most critical assets for business and. in practice, always takes the 
precedence over security. Seciu*ity measures that may cause net- 
work degradation, arc likely to be simply ignored. 




236 



DATA AND APPUCATIONS SECURITY XV/l 



As far as manageability is concerned, some functional requirements may 
be identified. Namely, firewall rules' evaluation should exploit: 

■ Grouping of requestors by common properties like affiliation and 
business role; 

• Classifications of Web service interfaces in a descriptive structure 
based on the functions they offfer or on their location. 

This way. a perimeter protection component could firstly parse some 
requestor’s general properties, like the organization, the business role 
or network parameters, which arc not application-specific. This lets 
a network or security administrator to fully define the pcrimetral pol- 
icy with a little knowledge of application details and manage it in a 
(semi)indepcndcnd fashion with respect to most modifications that ap- 
plication managers will make. 

Then, the Web services requested, or the functional class of services to 
which the one requested belongs to, should be taken into account. Using 
a superset of the actual requested service, according to a classification to 
be specified, may help in terms of ease of both definition of the policy by 
the security administrator (i.e. hc/she docs not need to know the actual 
service names and meanings) and management (i.e, the administration 
task is (semi)indcpcndent from changes in service names or creations). 

We shall develop on this descrition in the next section. 

4. Design and implementation guidelines 
4.1. Model 

The solution proposed here is based on the results of the work by 
Damiani et al. [7) that presents a soludon for an Auihorhaiion Filter 
for SOAP messages. Our architecture of the semantic-aware perimeter 
protection component has three main logical parts: a set of filtering rules 
representing the security policy and a mechanism to enforce it; a classi- 
fication of requestors based either on groups or roles; and a functional 
classificadon of Web services. 

The data structure that maintains the rules is stored persistently in 
XML and it offers an interface that permits to get a decision about 
allowing or dropping a SOAP message. It also provides other admin- 
istration interfaces, for modifying the rules and for synchronizing the 
requestors and Web services classifications according to a common on- 
tology that should be corporate- wide shared, between semantic-aware 
perimeter level filters and service level authorization filters. 

Requestors Classification. Requestors, as said, should be grouped ac- 
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Figure /. An example of reque5^tor/organiza(ionaJ role classificoiion 



cording to some general and application- independent properties, based 
on business roles, affliadons, etc. Figure 1 shows an example of requestor 
elassification based on their organizational roles, such as Cmiomers or 
Subsidiaries, Individual customers or Corporate customers and so on. 
Requestors classification represents the subject part of our authorization 
rules. Intuitively, more general groups (e.g. Customers) can be used for 
specifying broader rules (e.g. within an Internet banking context, “all 
customers could enjoy some services from the financial department”). 
More specific groups (e.g. CompanyI\ instead, could be used for finer 
rules (e.g. “Company 1 subscribed a trading on-line option, so Com- 
pany I's requestors could enjoy the trading services of the financial de- 
partment”). Individual requestors not falling in any group are treated 
as singleton groups. 

Web services Classincation. Web services, according to our pro- 
posal, should be classified into functional homogeneous categories and 
these categories, instead of single services, arc used as authorization oh- 
jecis. This way, perimeter access control performs a filtering that is 
(semi) independent from specific services and based on corporate-wide 
criteria. In the example just mentioned describing the requestors classi- 
fication (i.e. “Company 1 subscribed a trading on-line option, so Com- 
pany I's requestors could enjoy the trading services of the financial de- 
partment”), we are ruling the access to a family of services called Trad- 
ing, possibly grouping many actual services, like PurchaseSiock and 
ShowQuoie. Figure 2 gives an example of this Web services functional 
categorization. 

4.2. Authorization syntax and semantics 

Figure 3 presents the structure of authorization rules proposed by our 
model. Each rule is characterized by five attributes: 
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Figure i. Filtering Rules structure 



• requestor, ihc subject part of the rule, is a singleton (id) or a 
pair {id, location), where id could be a group or a role defined 
within a requestor classification, and location could be a range of 
IP addresses or a symbolic name. For convenience, the value ANY 
should be specified when each requestor’s id must be matched; 

m service, the object part of the rule, takes values from the Web 
services classification. For convenience, the value ANY should be 
specified when each service must be matched; 
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m direction has the value IN for rules applied lo incoming messages 
and the value OUT lor rules applied lo outgoing messages. Incom- 
ing SOAP messages could be requests from an external requestor 
towards an internal, protected Web service, or responses of an ex- 
ternal Web service to an internal requestor, the opposite holds lor 
outgoing messages. If the rule must be applied in both directions, 
for convenience the value BOTH can be set; 

■ response takes the value YES when the rule applies to a SOAP 
response only; it takes the value NO when the rule applies to a 
SOAP request only; and it is left undeclared when the rule does 
not depend on this information; 

■ penuit_deny has the value PERMIT for positive authorization and 
value DENY for negative authorization. A positive authorization 
states that, for requestors described by requestor, the categories to 
which the requested services specified in the SOAP Body belongs 
to. described by service, are available and the message can pass 
through. A negative authorization, instead, states that requestor 
is not authorized to require any Web service belonging to service. 
then the SOAP mes.sage must be dropped. 

4.3. Example of semantic-aware firew'aJling 

Following the classification examples of Figure 1 and Figure 2. Table 1 
presents an example of semantic-aware firewalling. The policy we want 
to enforce is: All customers have a home hanking account providing for 
some basic services like the account balance. Debit operations and on-line 
trading need specific hanking accounts. Only Company! has an on-line 
trading subscription for its personnel connecting from subnet I40.I2I.5. 
For this example, we assume that the message exchange pattern is in 
the request/response form. Accordingly, the policy defined in Table 1 
is composed by the following rules, to be evaluated sequentially from 
Rule 1 to Rule 6: 

Rule 1 specifies that incoming SOAP requests (direccion value - "in"; 

reeponae value - -NO") ftOm personnel of Company 1 (group -id Cooipanyl). 

or sub-groups of, connecting from subnet 140.121.5 (netaddr i«o 121 . s.- 
and requested services of the Trading category (category trading), 
or super- sets of. are permitted to pass through (p ertnic_deny value ■ 

"MRMIT" ). 

Rule 2 SpeciHes that Outgoing responses (dizeccion value > -out:; reaponae 
value - -YBS") to incoming requests ruled by Rule 1 are permitted. 




240 



DA TA ANDAPPLiCA TIONS SECURITY XVU 



/. Example of semantic-aware perimeter protection policy for some home 
banking services 





<requ«stor> 

<id> <gxoap.id> < /^roup.id> < /id> 

<IocatioD> <fietaddr> 140.121.6 # < /aetaddr> < /location > 
< /zequo8tox> 

<«ervlce> <c«to£ory> Trading < /category> < /s«rvice> 
<directioD valna = *'IB" /> 

<r8apon»o valuo ■ "HO” /> 

<ponltud«ay value • "PERKIT'* /> 


2 


<roque9tor> 

<ld> <gT0up.td> Cospas;! < /fTOop.id> < /ld> 

<locfctlon> <Mtaddr> 140.121.S.> < /iiot«ddr> < /location> 
< /r«queetor> 

<eerviee> <eaTe|ory> Trading < /category> < /eorvlee> 
<directioB value - "OOT” /> 

<reapo&ee value * "YES” /> 

<penU^«uy value » 'PERHIT" /> 


3 


<r«queiter> <id> <freup.ld> Cuitoaere < /gvoi^.id> < /id> < /r#queetor> 
<eervice> <cetegory> Debiciccount < /categorr> < /eervlee> 

<dlrectloa value ■ "AITY* /> 

<»erait^eaT value * "OEVY" /> 


4 


<reqneetor> <ld> <group.id> Cuatonere < /group.ld> < /ld> < /reqnestor> 
<aerv4ca> <category> HMae.B«Afcij)g < /categoxy> < / service > 

<dlr«etloB value • “IH" /> 

<re8pQaee value • "HD* /> 

<per«}t^eay value ■ ■PERMIT" /> 


B 

1 

1 

1 


<requeater> <id> <greup.id> Cnavenere < /gvoup.id> < /Jd> < /requaater> 
<eefvlce> <category> Boae^anklng < /category> < /servlce> 

<directioo value - •OUT” /> 

<reepooee value ■ *YES" /> 

<penic.deBy value = 'PERMIT” /> 


e 

1 


<requestor> ABY < /reqiiaator> 
<s«rv4ce> AKY < /»ervl«e> 
<dirBctlon value ■ '*B0TE” /> 
<pv«itjdeBY value • "PBJO" /> 



RiiJe 3 says that generic Customers, or super-groups of, cannot a:ccss 
services in the DcbilAccount category or sub-sets of. Both requests 
or responses, cither incoming or outgoing (direction value « "Any ')» 
arc dcnie<i and hence dropped (permit_deny value = "dbnv)« 



Rule 4 says that incoming requests from generic Customers or sub- 
groups of, requesting services of the Hoine_Banking category, or 
super-sets of. arc permitted to pass through; 
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Rule 5 specifies that oulgoing responses to incoming requests ruled by 
Rule 4 arc permitted. 

Rule 6 is a default rule staling that if any of the previous does not 
applies, then we want to drop the messages. 

5. Conclusion and Future Work 

In this paper we gave a functional description of a scmantics-awarc 
firewall, a perimeter protection component matching a requestor's gen- 
eral properties and the functional class of requested Web services against 
a locally stored axess control list. 

The benefits of our approach arc several 

■ the solution is scalable by designing filtering rules of increasing 
complexity (i,c. simpler and faster controls for direct Internet traf- 
fic for a first layer of filtering, possibly followed by more detailed 
controls for messages already screened); 

■ the solution can be customized according to the needs of specific 
busincs.scs; 

m untrusted requestors do not interact in an unflltcrcd fashion with 
Web services, which arc highly critical components; 

Moreover, the perimeter protection solution described can be smoothly 
integrated with the solution for fine-grained access control for SOAP 
'Web services developed in [7j by some of the authors, composing this 
way an overall comprehensive approach to SOAP Web services security 
issues. 

However, the solution proposed is not complete and many issues arc 
still open. Other more complex message exchange patterns should be 
considered. Considering filtering techniques, we plan to extend our pro- 
posal to stateful semantic-aware firewalls by correlating messages ex- 
changed according to HTTP and SOAP protocol semantics. Another 
important is.sue for our work is the full integration between this semantic- 
aware perimeter level and the fine-grained access control level, and the 
development of solutions for coordinating the two levels of security poli- 
cies. 
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Absiract: Exchange proiocoU play an importani role in application areas such as e- 

commerce where protocol pariicipams require imitual guarantees that a 
transaction involving exchange ofitems has taken place in aspeciftc manner. A 
protocol is fair if no protocol participant can gain any advantage over an honest 
participant by misbehaving. This paper pre.sents a family of fair exchange 
protocols for two participants under a variety of assumptions concerning 
participant misbehaviour, node reliability and message delays. 

Keywords: Fair Exchange, Security. Digital Signatures. Crash tolerance, Distributed 

Systems, Trusted Third Party. 



1. INTRODUCTION 

Fair exchange protocols play an importani role in application areas 
where protocol participants rtx^uirc mutual guaranlecs that an exchange of 
data items has taken place in a specific manner. An exchange is fair if a 
dishonest participant cannot gain any advantage over honest participants by 
misbehaving. Two- participant fair-exchange protocols that make use of a 
trusted third party have been studied extensively in the literature (e.g,» |1, 5, 
1 1 ]); these protocols maintain fairness even if the dishonest participant can 
tamper with the protocol execution in an unrestricted (malicious) manner. 
They however require that an honest participant's node execule the protocol 
correctly - suffering no failures. We call them non-faull-lolcranl. A crash- 
tolerant fair exchange protocol, on the other hand, ensures no loss of fairness 
to an honest participant even if the participant's node crashes during the 
execution, provided il evenlually recovers [4]. 

In this paper we develop a number of fair exchange protocols under a 
variety of assumptions concerning i) user misbehaviour, ii) node failures and 
iii) communication delays. The development is sysicmalic: we begin by 
classifying dishonest participants into resiricied ahusen (they cannot tamper 
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with the protocol execution in an arbitrary manner) and unrestricted or 
maheious abusers, and the communication model into synchronous, where a 
known bound on message delays exists, and asynchronous, wt develop the 
first protocol under the most constrained set of assumptions: restricted 
abuser, synchronous communication and no fault tolerance. We then relax 
the restricted abuser assumption to malicious abuser and then the synchrony 
assumption into asynchrony. The resulting family of non*faull-loleranl 
protocols is then transformed into a family of crash ‘toleranl ones. 

A major advantage of our approach is that it enables a reader to gain a 
deeper understanding of the impact of a given set of assumptions on the 
problem of fair exchange; it also highlights the relationships that exist 
between fairness, fault tolerance and communication delay assumptions. We 
first describe the problem and the underlying system models (section 2), and 
then develop a family of non-fault-tolerant protocols (section 3), followed by 
their crash-tolerant counterparts (section 4), Section 5 summarises the 
characteristics of the protocols developed and concludes the paper. 



2. SYSTEM MODELS AND THE PROBLEM 
DESCRIPTION 

We consider two mutually untrusting users, Ua and Uh» who have data 
items Ia and 1 b respectively that arc unknown to the other user prior to the 
exchange. User U*. X €(A, Bj, intends to send in return for receiving ly, 
where Y €(A, B) and Y S X. P« denotes the process that executes an 
exchange protocol on behalf of user U* on his node Nx- 



Ua 




Ub 



Our distributed exchange system (Figure 1) has a third node hosting the 
trusted third party (TTP) process. The exchange must preserve fairness as 
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well as non- repudiation: a user gels irrefutable evidence of the actions 
performed by his process (to guard against the other user’s false denial of the 
occunence of an action or event). 



2.1. Classifying LI ser M isbeha viour 

Generally, the problem of fair exchange is addressed in a context where 
a dishonest user, say Ub» totally controls the behaviour of Pg and tries to 
undermine every attempt to ensure fairness and non-repudiation. We term 
those dishonest users as molicious abusers and distinguish such users from a 
class of restricted abusers: a dishonest user is said to be a restricted abuser if 
he is unable to obtain the values of variables or procedures contained in a 
piece of (binary) code which his local process receives from the TTP and 
uses during protocol execution. Say, user Ub i^> a restricted abuser and the 
TTP gives Pb a piece of code Db that contains, say, some secret encryption 
keys. By our definition. Ua cannot obtain the keys in fls by visual inspection 
or through a trace analysis even after Pg has executed Ua- The definition 
docs not however restrict the ability of Ub to delay, block, inspect, or tamper 
with any message which an execution of FIb generates or is destined to 
receive. 

One way to realise our notion of a restricted abuser is to have each Px 
receive the TTP code fix via a secure channel and execute it in a tamper- 
proof part of the user node. We note here that there is much interest in 
developing tamper-proof computing subsystems by the industry led Trusted 
Computing Platform Alliance, TCPA [8], Further, smartcards can be used to 
achieve such tamper-proof, computing subsystems for small, critical 
computations (2. 10|. Thus, developing fair-exchange protocols under the 
restricted abuser model is of practical interest, and also exposes the benefits 
that the model has to offer. 



2.2. Classifying Node Behaviour 

A fair-exchange protocol is fault-tolerant if it ensures that fairness is 
preserved to an honest participant despite the participant’s node suffers 
failures of the assumed type. In other words, an honest user does not suffer 
loss of fairness when his node is unreliable. We consider two types of node 
behaviour: 

Reliable: An honest user's node never fails. 

Crash-recovery: An honest user's node fails by stopping to function 
(crash); it recovers within some finite (but unknown) time after a crash and 
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may crash again after its recovery. An honest user’s node has access to a 
stable store whose contents survive the node crash. 

When a user node is regarded to be reliable, the cause of any node crash 
is attributed to the user who has misbehaved and is therefore not entitled to 
any fairness guarantee. This is the traditional view taken in the TTP-based 
protocols (e.g., [1.5, 1 1|) which are therefore not fault- tolerant (sec [4]), In 
line with the existing, non-fault-tolerant protocols, the TTP is assumed to be 
reliable and secure against intrusions and Trojan horses. 



2.3. ClaSvSitying Communication Delays 

Communication between correctly functioning processes is assumed to 
be resilient to network failures: a message loss is tolerated by retransmission 
and a message corruption is detected using encryption and reduced to a 
message loss. A network intruder is therefore assumed to be a restricted 
abuser: a message in transit is a black box to him; he cannot modify it and 
have it undetected at the destination. He can only delay a message from 
being accepted at a destination. We consider two types of network intrusion: 
intruder gives up delaying a given message transmission after a known 
period of time or after some unknown finite lime, leading to two models: in 
the synchronous model, correct processes exchange messages with delays 
bounded by a known D; in the asynchronous model, D is finite but unknown. 



2.4. Properties of a fair exchange Protocol 

A user is honest if he makes no attempt to modify the behaviour of a 
protocol process except through the permitted operations. 

Termination: Any execution of the protocol terminates for an honest user 
Ux« Termination for an honest Ux can be either a normal termination in 
which Px delivers ly to Ux or ^ti exceptional termination where Px informs 
Ux that the exchange is unsuccessful, 

No_Loss_0/_Faimess: IfPx of honest Ux terminates exceptionally, Uy 
does not receive lx, 

Non-repudiation: when Px delivers ly to honest Ux, it also provides 
irrefutable evidence against any false denial on ly having been sent by Uy. 

The above properties arc met trivially if and terminate always 
exceptionally. 

Non-Triviality: If Ua and Uq are honest, both are guaranteed to have 
normal termination. 

Non-triviality is easy to guarantee for the synchronous, non-fault-tolerant 
case. When the fair-exchange protocol is deterministic (not probabilistic) in 
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nature, honesty of both the users alone is not sufficient to guarantee non- 
triviality for the case of crash-recovery nodes and synchronous 
communication, as well for the case of asynchronous communication. The 
reasons for this inability arc as follows. In crash -recovery model, the bound 
on the time taken by an honest user node to recover from a crash is unknown 
and a dishonest user may never allow his node to recover. So. a coneetly 
functioning process (of an honest user or the TTP) that is waiting too long 
for a message from a user process cannot resolve whether the latter is honest 
and its message is unduly delayed due to a crash or is dishonest and is not 
going to transmit the expected message; similarly, in the asynchronous 
model, it cannot resolve whether the user process from whom a message is 
expected is honest and its message is still in transit or is dishonest and the 
message will not be transmitted at all. (Readers familiar with the FLP 
impossibility result [3] may find these arguments remarkably similar,) 
Therefore, meeting the termination property would mean that an execution 
of the protocol may have to terminate exceptionally even if both users are 
honest. Therefore, the necessary condition for ensuring non-triviality is that 
the honest users be willing to re-execute the protocol after every exceptional 
termination; the sufficient condition differs with the combination of 
assumptions and is stated below: there must be an execution in which 

(i) user nodes do not crash, for the case of crash-recovery nodes and 
synchronous communication; 

(ii) message delays do not increase, for the case of reliable nodes and 
asynchronous communication; and, 

(i) and (ii), for the case of cra.sh-recovery nodes and asynchronous 
communication. 



2.5. A&sumpUons, Notations and the Exchange 
Preliminaries 

In all our protocols, the TTP, a.ssumcd to be secure and reliable, is used 
to set-up the context for. and to initiate, the actual exchange. We make the 
following additional assumptions. 

Ai\ Processing within correctly functioning nodes is synchronous: 
delays for task scheduling and processing arc bounded by a known constant, 

A2: The clocks of the TTP and the functioning nodes of honest users 

arc synchronised to real-time within a known bound which, for simplicity, is 
assumed to be zero. A recovering node receives the current time from its 
user. 
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Notations 

M: a message; 

Va (Vb): procedure to verify if (1^^) satisfies its description Za (Zb) 
advertised by Ua 

eK(M): encryption of M using key K; 

Sigx(M): signature of Px, X 6 {A, B},on M using the private key of Ux; 

Sigrrp(M): TTP’s signature on M. Signatures are both signer- and 
content-dependent, and are verifiable using the signer’s public key. 

L; a label that identifies a given exchange; 

N: a large random number (nonce) generated securely by TTP to 
uniquely identify messages of a given execution of the protocol for a given 
exchange; and. 

H: one-way and collision -resistant hash function: it is not feasible to 
compute from H(N). N nor another N’ such that H(N) = H(N’), 

n«: contents of a message sent by the TTP to P, to initate the exchange 
phase. 

When a party Z € {A, B, TTP} sends a message M it also includes 
Sig2(M) as the evidence of origin for M, A recipient accepts a received M 
only if the accompanying Sig2(M) is found authentic. For brevity, we will 
not make the details of this verification explicit and a received message will 
only refer to a message received with an authentic evidence of origin; further 
the pair {M. Sig2(M)} will simply be written as M which will be indicated 
by its significant fields. 

Exchange Preliminaries 

All our protocols are structured into two phases: the start- up phase 
followed by the exchange phase when the actual exchange of promised data 
items takes place. During the start-up phase, the following three steps are 
carried out: 

Step O.I: Each Ux approaches a trusted authority TAx to generate a 
verification procedure Vx using which any party can verify if a data item I 
satisfies specification £x* For example, if Ib is a piece of software S. Ub tnuJ’t 
approach a software licensing authority (trusted by Ua) who evaluates S 
against the specification Z3 that Ub advertised. If satisfied, the authority 
computes an evidence of evaluation Ey * H(S); Vb is then generated as a 
program which contains Eb evaluates the predicate Ee = H(I) when 
invoked to verify a data item I, Using the conventional notations, the step is: 



^ TA.: (I„ Z*); 

TA.^U.:(V^,Z«. Sigu^(V^, 

Ia)1; 



Ub-»TAb: (Ib, Eb); 

TAfl— >U jj;{Vb, Zb. SigTA b(Vb, 

2b)); 
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Step 0.2: Users exchange their (V, I, SigT*(V, L))» decide on the TTP 
and on a (future) lime Tgx when Ihc TTP should inilialc Ihc exchange phase, 
Siep 0.3: Ua TTP: (A, Tex, {V*, Ia). {Vb. Er}, ntAfi): similarly, 
Ub-4TTP: (A, B.Tex. {Va> Sa}. {Vb, EBl^rttsA). The last field rttx vis Ux^s 
estimation of the round trip time between its node and Ny, 

Upon receiving messages sent in step 0,3, the TTP verifies whether all 
fields except the last one arc identical. If so, Ihc TTP decides on a unique L 
for the exchange if the exchange is new; generates a nonce N for the 
exchange phase and records N in a variable flc//v^_run#(L)= N. If Ihe 
exchange is not new, it only generates a new nonce and records il in 
active _run^h). It then sends Ob to Na and FIb to Nb which include the 
parameters L and H(N) which arc used to identify messages of a given 
execution . The nature and Ihc complete contents ofH’s sent by TTP depend 
on the exchange phase of Ihc protocol for a chosen combination of various 
assumptions discussed earlier. 

TTP Involvement 

A protocol is said to keep TTP offline if it is possible for honest user 
processes to achieve normal termination without interacting with TTP after 
the exchange phase is initialed. Such a protocol is also called opiimisiic in 
the lilcralurc. If TTP is not off-line, it is said lo be on-line. 

A protocol is said lo use a siate^keeping TTP if it requires the TTP to 
respond to messages from user processes for an unspecified amount of lime; 
the protocol is said to use a state ^relinquishing TTP if it requires the TTP 
only for a specified duration after the exchange phase has been initiated. 
From cost point of view. TTP is prefened to be offline and state- 
relinquishing. 



3. NON-FAULT-TOLERANT FAIR EXCHANGE 
PROTOCOLS 

3.1. Restricted Abuser, Synchronous Communication 
(Protocol PI) 

The TTP sends a code IT a to Pa and ITb to Pg, Pa ^nd Pa perform Ihe 
exchange phase of the protocol PI by cxeculing the code given to Ihcm. 
Embedded in Ox afc L, H(N), Vx, A, and keys Ka and Kb, each with TTP’s 
evidence of origin. A is set lo D (the known bound on message delays). Ka 
and Kb are symmetric and random session keys. When a dishonest Ux'^^nly 
a restricted abuser, he cannol obtain Ka and Kb from Tlx nor undeteclably 
modify Vx embedded within Fix. However, Ux can delay, block, inspect, or 
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tamper with any message Px generates or is destined to receive while it 
executes Fix. 

On executing n*, Pa first verifies whether I* (input by Ua) passes 
embedded within Ha. Only if Ia passes the verification, Pa continues the 
execution: it encrypts the verified Ia using Ka» forms a message Ma and 
encrypts Ma with Kr. The encrypted Ma, like all messages sent by Pa. 
contains a signature generated using the private key of Ua and is sent to Pq. 
(Any message without valid signature is ignored and hence assumed not 
'received’ by a destination,) P& decrypts the received Ma» and if the contents 
arc correct, it sends an acknowledgement AckB(A)to Pa. Pb similarly sends 
Mb to. and expects to receive AckA(B) from. Pa. The message exchange 
between Pa and Pg are depicted in Figure 2. where a process sending a 
message shown along an out-going arrow is conditional upon that process 
having received the messages shown along all incoming arrows, Px. after 
receiving Fix, starts executing both the rounds concurrently: send Mx and 
wait for Ackv(X) while waiting for My before Ackx(Y) can be sent; a 
timeout of 2A is used to avoid indefinite waiting. 







ftounJ I 



Round 2 



Figure 2. Proiocol PI; Message exchange rounds beiween user processes. 

Table 1 summarises the messages used and the intended direction of 
their flow, A message is indicated by its significant fields, the first three 
fields will be: the label L, the sender, and H(N). Note that the first and the 
third message fields uniquely refer to a given execution. 

The condition on Pa (Pb) for computing 1 b (Ia) from Mb (Ma) is: both 
Mb (Ma) and AckB(A} (AckA(B)) must be received within 2A time after 
receiving FIa (Fig) from TTP. If Pa receives only Mg (within 2A time), it asks 
TTP to resolve the exchange by sending message Res a that contains both Ma 
and the received Mb. If it receives neither Mb nor Ac)Cb(A), it requests TTP 
to abort the exchange by sending message RcfiA that contains only M a. TTP. 
having initiated the exchange at its clock time Tex* executes the following 
steps at Tex + 

Step TI: if it has received Rcq from both processes or Res from at 

least one process, it sets variable outcome = resolved and resolves the 
exchange by sending Mttp(X) to both processes; 
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Siep T2: if il has received Rcq from only one process, it sets outcome 

= aborted and aborts the exchange by sending AborlTTp(X) to both processes; 

Step TS\ if it has received no message, it sets variable outcome to 
unknown; 

Step T4: it terminates (as a slate- relinquishing TTP). 



1 >A = eK^{W 


®B=eKB(lB) 


M* = eKa(L. A. H(N), ®*); A -» B 


Mt,= eKA(L,B. H(N),Ob);B->A 


Ack;,(B) = (L, A. H(N), H(Mb), 
My jack)', A ^ B 


Acke(A) * (L, B, H(N), H(Ma), 
My jack)', B -» A 


RcSa = (L, A, HfN), Ma, Mg. 
Resofve^requesl); A -* TTP 


Resg « (L, B. H(N), Mg, 
Resolve request); B — * TTP 


Rcqa » (L, A. H(N), Ma. 

Abort recfuesi)’, A — » TTP 


RcqB = (L, B. H(N). Mr, 

Abort ^request); B -♦ TTP 


MTTr(A) = (L. TTP, H(N), Mb. 
My act), TTP -* A 


MttpOB) » (L, TTP. H(N), 
My^ack);TT? -» B 


AbortTTP<A) “ (L, TTP, H(N), 
Abort jgranied. A); TTP A 


Abortnp(B) » (L, TV?, H(N), 
Aborr_granied, B); TTP -> B 



Table I. Description of messages used in Protocol PI. 



An honest P 4 lerminalcs normally by receiving either Mb and Acke(A) 
or Mrrp(A)i exceplionally by receiving AboftrrKA)- The protocol keeps TTP 
off-line (step T3 above). The four properties of fair-exchange (Seelion 2.4) 
arc mel by PI because: (i) dishonest user, say Ug, is a restricted abuser, so he 
cannol force lo deliver against the protocol conditions nor can he 
obtain and Kg from Fig; (ii) an honest Pa sends AckA(B)to Pg only if it 
receives Mg in a limely manner; (iii) any message that Pa sends to TTP 
reaches before Tex'*' 4A; and. (iv) TTP's response, if any, is identical lo both 
Pa and Pg. 



3.2. Malicious Abuser, Synchronous Communication (Pl.l) 

1 . Pl.l is the same as PI except some messages of Ihc exchange phase 
have different contents. This is because a dishonest user, say Ug, can 
obtain Ihe keys Ka Kb in the program Fig supplied by TTP al Ihe 
start of Ihe exchange pha.se. The following changes arc needed: 
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2. FIa 2 message containing all parameters as before except Kb* FIa * (L 
H(N), Va, a, KA);simiIarly, ITd = (L, H(N), Vq. A, K»). Further, TTP 
should not have used Ka and Kn before, 

3. Ha does not contain Ke means that Pa cannot encrypt Ma with (sec 
Table 1). Therefore Ma is (L, A, H(N). and Mb is (L. A. H(N). Oe). 

4. Pa includes Ka in its Ac)Ca(B) so that if Pb has both Ma and AckA(B) it 
can terminate normally without having to contact TTP, So. AcIca(B) of 
Table 1 becomes (L. A, H(N), H(Mb), Ka) and Acku(A) becomes (L. B, 
H(N). H(Ma), Kb). 

5. Finally. Mrr?(A)by which TIP instructs Pa to resolve the exchange, 
must contain Kb: Mrrp(A) = (L, TTP, H(N). M^, Kb). Also, Mttp(B) « 
(L, TTP, H(N), Ma, Ka). 



Remark; Dispute Resolution: Non-repudiation guarantee ensures that 
when honest Pa terminates normally, it has evidence that Pa sent the item 
which Pa delivered to Ua. However, if Ue is dishonest, Ua might find Ib not 
passing the verification test Vb which it agreed with Ug in the start-up phase. 
Consider this scenario; malicious Up obtains Kp from Ob, generates M'b 
with authentic evidence of origin but with 1 b, and transmits M’s in place 
of Mfj. Since Ra does not contain Kq (sec modification 1 above). Pa cannot 
check whether the !'□ in the received M'p meets V[jat the end of the first 
round itself (see figure 2). Since M’q found to have authentic evidence of 
origin, it will send AckA(B) that contains Ka, thus letting Pb terminate 
normally without ever contacting TTP. Only after being delivered of Tg, Ua 
can find out that I’b does not pass V^and that Ub has been dishonest. 

If Up is a restricted abuser, the above scenario cannot arise: Rd 
tamper-proof relative to the abilities of Up and therefore is can contain Ka 
using which Pp encrypts Mq in Pl. Since Ub cannot obtain Ka, he cannot 
modify Mpto M’s^nd make Pa accept M’p.Thus. in PI , what Ua receives is 
guaranteed to be the expected one, 

PI . 1 only guarantees that Pa delivers to an honest Ua what a malicious 
Ub ociually sent in exchange for Ia, not necessarily what Ub has pledged to 
send. The TTP can guarantee fairness to Ua such a scenario, by contacting 
the trusted agent TAp employed to generate Vp which Ua accepted. This 
corresponds to a weaker form of fairness enforcement in the hierarchy of [9]: 
fairness can only be guaranteed with the help of a trusted agent outside the 
fair-exchange system (figure 1) and without any cooperation from Ug, The 
issue of post-exchange dispute resolution is discussed and addressed in (6, 7| 
for malicious abusers. The protocols of [6. 7| make use of inverse and 
compatible keys to verify an encrypted item without decrypting it. Using 
these special types of encryption keys, Pl.l can also be modified to ensure 
that an honest user receives in a normal termination only the item he 
bargained for. The modification is simple and shown in [2]. It preserves the 
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2-round structure which is provably optimal [5]. The protocol of [6], like 
Pl.l, keeps the TTP off-line but requires 4 rounds when both users are 
honest. 



3.3. Restricted and Malicious Abusers, Asynchronous 
Communication (PI A and Pl.l A) 

Protocols PI and Pl.l are not appropriate for the asynchronous model. 
This is not surprising as [5] shows that, in the non-fault-tolerant case, there 
cannot be an asynchronous protocol that works with a TTP that is off-line 
and state-relinquishing, and goes on to present a protocol with an off-line 
and state-keeping TTP. We here present protocols PI A and Pl.l A with an 
on-line and state-relinquishing TTP, by deriving them from PI and Pl.l 
respectively. The derivation is simple: in round 2 (see figure 2). pj^ sends 
Ackj<(Y) to TTP, not to Py; it then waits for either Mttp(X) or Abortrrp(X). 

In the start-up phase, TTP should obtain round trip time (rtt) 
measurements with each Px (as rtt* and rtts) and estimate 2A 
maximum (rttA, rttAU. 

TTP: 

Mhen (clock ■ T«x) Oo { 

send flu to Pa; send n« to P»; Set of K M Bagt • 4 J; 
repeat i receive IM); deposit M in I uncii clock < Te>* 

i/ (AckaiBJe H_BagL end AckaCA] e H_6agu) 

then (send Ack»{A) to Pa; send AckA(Bf to P»; l // resolved 
else (send M>ortrrp(Al to Pa/ send Aborttr^CB) to P«; ) | /• end do 
Figure 3 Pseudo-code for TTP in prococols Pi A and Pl.l A. 

If honcsl users re-cxcculc the protocol for a given exchange after every 
exceptional termination, non-trivialiiy is guaranteed if there exists an 
execution in which the message transfer delays between Pa and TTP do 
not exceed the A determined by TTP at the start of the exchange phase; i.e.. 
if message transfer delays do not increase during an execution. 



4. CRASH-TOLERANT PROTOCOLS 

4.1. Restricted Abaser, Synchronous Communication (P2) 

Two extensions arc necessary for protocol PI to be crash tolerant. 
Pessimistic (synchronous) checkpoiniing: Px of an honcsl user logs every 
received message and check-points its stale before the received message is 
processed. Thus, in fig. 2. an honest Px must receive and log the messages of 
the incoming channels before it can send out a message. Siaie^keeping TTP: 
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in step T4, the TTP docs not tenninate the execution, but continues to 
operate depending on the value of outcome: if outcome is unknown, the TTP 
executes steps T1 -T3 after a period of 4 A time; otherwise, it responds to a 
message from Px with Mttp(X) or AbortTTp(X), if outcome is resolved or 
aborted respectively. This modification permits a recovered Px to terminate. 
Note that when TTP sets outcome to resolved or aborted, it is ineversible. 

Impossibility of making PI Crash-tolerant 

Even with the use of pessimistic logging and state-keeping TTP, PI 
cannot become crash-tolerant even if the dishonest user is a restricted abuser. 
Consider the following scenario. Let Na crash during the second round 
shown in figure 2 and before Pa receives Acks(A); that is, Pa has logged Ia, 
FIai sending of Ma. and Mg. Let dishonest Ub block all messages Pa sent to 
Pq but retains a copy of these incoming messages, Pg, having received no 
message from Pa within 2A time, will send Reqp for which TTP will respond 
by setting outcome = aborted and sending AborlTTp(B). Say Ug blocks 
AbortTTp(B) as well and crashes his node. The recovered Pa will find itself in 
having received only Mb and will send Res a which, say, reaches TTP after 
outcome was set to aborted; TTP’s response will be to send Abort-rn>(A) to 
Pa. Let Ug re-boot Nb, delete TIq from stable-store, and adjust the clock to 
make it appear as if the exchange phase is being executed for the first time. 
He replays the arrival of FIb and of the blocked messages of Pa exactly at 
those instances when they arrived during the first execution. Since Pg 
‘receives' both Ma and AckA(B), it delivers Ixto Uq, 

Outline of Protocol P2 

At the core of Pi's inability to be crash tolerant is the fact that having 
both MA and AckA(B) is a sufficient condition for Pg to deliver Ia without 
consulting TTP at all. To remedy this, we need to add one more round to 
protocol PI which Px executes after having executed the first two rounds 
(concurrently) and check-pointed its state. In the third round, shown in 
Figure 4, Pa sends a second acknowledgement AcIc^a(B) to pg indicating the 
reception of AckB( A) and Ma. 




Figure 4 The addUional message mund in P2. 




Svsiemaiic Development of a Family of Fair Exchange Protocols 



255 



If docs not receive Ack^a(A) within 2 A time after it has sent 
Ack^A(B), Pa to TTP by sending First_AckSA that contains both 

AckA<B) and AcJcbCA). TTP, after receiving First^AckSA, sends Ack^KA) 
to Pa only if it has not earlier received Rc<)a {which would have resulted in 
sending AbortTTp(B) to Pg). Thus, the condition for normal termination of Pa 
is: receive<^(Ack^ 2 A(A)), where Za€{B, TTP}. By symmetry, the condition 
for normal termination of Pg is: w^/verf(Ack^ 2 B(B)), where Za € (A, TTP}. 
Three messages used in addition to those used in PI arc shown in Table 2, 



Ack'A(B)=(L, A, H(N), 

H(AckB(A)), Myjick^)\ A— » B 


Ack'B(A)=(L, B, H(N). 

H(AckA(B)), My_ack^y, B ^ A 


First_AcksA = (L. A, H(N). 
AckA(B), AcksfA)); A -> TTP 


First Acksa = (U B, H(N), 
Acke(A), AckA<B)); B TTP 


Ack'rrp{A) = (L. TTP, H(N), 
II(AckA(B)), Myjick’y. TTP -» A 


Ack^iMB) = (L» TTP, H(N), 
H(Acka(A)), My_ac^); TTP 



Table 2. Description of dddilional messages used in P2. 



4.2. Malicious Abuser, Synchronous Communication (P2.1) 

Protocol P2.1 is the same as P2. except that some of the messages used 
need to be changed: 

1 Oa, Ma, Mttp(A), Ha, Me, and Mttp(B) of Table 1 change as mentioned 
in Section 3.2, AckA(B) and AckuCA) remain exactly as shown in Tj^Ic 
1 . 

2, In Table 2, My ack * Kb in Ack^a(A) and in AckVp(A); similarly, 
My_ack * Ka in AcIc^a(B) and Ack^TT7(B). 

Remark: Simple Extension to Asynchronous Communication model P2 
and P2.1 work correctly in the asynchronous model if TTP computes A 
during the start-up phase as described for PI A and PI, lA, 



4.3. Malicious and Restricted Abusers, Asynchronous 
Communication, on-line TTP (P2A and P2.1A) 

These protocols arc obtained by making PI A and P1,1A crash-tolerant 
by having process Px pessimistically checkpoint its state (as in P2 and P2.1) 
before processing a received message and by making TTP state -keeping. The 
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latter is done as follows: for any message received from Px after Tex *** 
TTP sends Acky(X) lo Px if both AckxlB) and Acka(A) have been received 
before Tgx 4A; otherwise il sends Aborl'n'p(X), 



5. SUMMARY AND DISCUSSIONS 

Table 3 summarises the protocols’ characteristics using the following 
abbreviations: 

♦ a dishonest user (DU) can be either a restricted abuser (RA) or a 
malicious abuser (MA), 

♦ communication delay model (C) can be synchronous (S) or 
asynchronous (As), 

♦ faults tolerated (FT) can be none (No) or crash (Cr), and 

♦ the TTP can be cither off-line (Off) or on-line (On), and either state- 
relinquishing (Sr) or state-keeping (Sk). 



Protocol 


DU 


C 


FT 


TTP 


PI 


RA 


s 


No 


Off/Sr 


PU 


MA 


s 


No 


OfF/Sr 


PlA(Pl.lA) 


RA(MA) 


As 


No 


On/Sr 


P2 


RA 


S/As 


Cr 


OfT/Sk 


P2.1 


MA 


S/As 


Cr 


OWSk 


P2A(P2.IA) 


RA(MA) 


As 


Cr 


On/Sk 



Tables. CharacicrisUcsofihe Proiocola Developed. 



On-line TTP: sfafe-relinquishing vs. stale-keeping. Because of its 

simplicity, a non-fault-tolerant protocol with an on-line TTP is likely in 
practice, and a need may later arise to enhance the protocol to be crash- 
tolerant. Can an online-TTP protocol be made crash-tolerant simply through 
message logging, regardless of whether the delay model is synchronous or 
asynchronous? The answer depends on whether the non-fault-tolerant 
protocol keeps the TTP state-relinquishing or state-keeping. Our protocols 
Pi A and Pl.lA suggest that it is possible to design onlinc-TTP protocols 
that keep the TTP state-relinquishing even with asynchronous delays. In 
making them crash-tolerant, we have to make the (on-line) TTP a state- 
keeping one (see P2A and P2.1A in Table 3). Thus, the answer to the above 
question is yes, provided the issue of state -relinquishing vs. state-keeping 
TTP is given due consideration. 
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Optimising the cost of message logging. The work by [4] proposes a 
logging-based approach lo achieving crash-tolcrant fair-ex change. Ii defines 
a point of no return for a user process, and claims that if the process would 
synchronously log all received messages before entering this point, then 
logging of other received messages can be done asynchronously. Their 
definition of point of no return suggests that there is only one such point for 
each process (Secdon 3,2 of [4]), We remark here that our protocol P2.1 
without cheek-pointing and message logging is identical to the time-optimal 
protocol (scheme 3) of [5] which is asynchronous and non- fault- tolerant. 
Applying the approach of [4| to make this protocol crash-tolerant docs not 
work: the point of no return for honest Pa turns out to be its sending Ma to 
Pg (sec figure 2, round 1); suppose that Na crashes in round 3 (sec Fig, 4) 
after Pa has sent Ack^A(B) but before Acke(A) and Mb were to be logged by 
the asynchronous logging scheme; note that Ack^A(B) contains Ka (see 
Section 4,2), Honest Ua suffers loss of fairness, even if Ug ttot 
misbehave; to avoid loss of fairness. Pa must also log all received messages 
before sending Ac1c^a(B)« It appears that some protocols can have multiple 
points at which pessimistic logging is essential. Given that the number of 
messages received by a user process in a given execution is small, attempts 
to minimise the overhead of logging may not be worth the effort after all; 
further, every message received (and logged) may be useful later in any 
dispute resolution. 

Acknowledgements 

This woric is funded by the UK EPSRC grant GR/N35953/01 
(Information Co-ordination and Sharing in Virtual Enterprises) and by the 
European Union Project IST-200 1-34069 TAPAS (Trusted and QoS-Aware 
Provision of Application Services). Our thanks arc due also to the 
anonymous reviewers of the 1 7^ IHfP Conference on Database and 
Applications Security. 



6. REFERENCES 

1 1 1 N. Asokan, M. Schunier and M. Waidner. Asynchronous protocols for oplimisiic fair 
exchange. IEEE Symposium on Rtsearch in Security and Privacy, pp. 86-99, 1998, 

(21 P. Ezhilchelvan and S. Shrivastava. Systematic Development of a Family of Fair 
Exchange Protocols (Full Paper). Technical Report CS-TR'S20, School of Computing 
Science. University of Newcastle. December 2003. 

(31 M.J. Fi.scher, N.A. Lynch, and M.S. Paterson, "Impossibility of Distributed Consensus 
with one faulty Process, ” Journal of the ACM. Vol. 32, No, 2. pp. 374-382. April 1985. 




DATA ANDAPPUCATIONS SECURITY XVU 



P. Liu. P. Ning and S, Jajodia. Avoiding Loss of Fairness Owing lo Process Crashes in 
Fair Daia Exchange Protocols. Inemaiional Conference on Dependable Systems and 
Network, pp. 631-40, June 2000. 

B. Pfilzmann. M, Schumer and M. WaJdner, Optimal Efficiency of Opiintistic Contract 
Signing. Prcc. ACM Svmp. on Principles of Distributed Computing. New York, 1998, 

1. Ray and 1. Ray. An Optimistic Fair Exchange E-commerce lYotocol with Automated 
Dispute Resolution. EC-Web 2000, pp. 84-93, 

I. Ray. I. Ray. N, Narasimhamurthy: A Fair-exchange E-commerce Protocol with 
Automated Dispute Resolution. DBSec 2000, pp. 27-38. 

Trusted Computing Racfomi Alliance. http:/Avww.irustedpc.org. 

H. Vogt, H. Pagnia. and F, C. Gartner. Modular fair exchange protocols for electronic 
commerce, 15th Annual Computer Security Applications Conference, pp, 3-11, Dec, 
1999. 

H. VogL H. Pagnia, and F, C. Gartner. Using Smart cards for Fair-Exchange, WELCOM 
2001. LNCS 2232, Springer, pp. 101- 1 13, 2001, 

J Zhou and D, Gollmann. Evidence and non-repudiation. Journal of Network 
and Computer Applicaiion.s. 20(3):267-281. July 1997. 




VI 



ACCESS CONTROL MODELS AND TECHNOLOGIES 




HIGH-SPEED ACCESS CONTROL FOR XML 
DOCUMENTS 

A Biimap-based Approach 



Jong P. Yoon 

Ctnltr for Advanced Compmer Sutdie.^, Universiry of Louisiana, Lafavette, LA TOSOd-dSSO 



Absiract; One of the impononi taskA of managing eXiensible Markup Language (XML) 
documenis isio uniformly specify and securely mainiain both largei documenis 
and auihorizaiion policies. However, since existing techniques decouple access 
authorization from query processing, the query processing time with access 
control is not satisfactorily fast. The access control requires the overhead in 
addition to the time required for query processing, and the powerful expression 
of authorization policies makes it impossible to accelerate the determination of 
access authorization. In this paper, we propose a biim^-based access 
authorization technique for both fast and secure .services of XML documents. 
The authorization policies are encoded into a bitmap index and further to be 
coupled an index of XML documents. User access requests are encoded into 
bitmap-masks. By applying bit-wise operations of a bitmap-mask to the 
authorization bitmap index, authorization can be determined significantly fast. 
The contribution of this paper includes I) the dual goals achieved for fast and 
secure accesses to XML document collections, and 2 ) early propagation of 
subjects and objects in bitmap indexes. 

Key words; High-speed access control, High-speed query processing. Bitmap-based 
Approach 



1. INTRODUCTION 

The extensible Markup Language (XML) is a dc facto W3C standard for 
repres enting and exchanging information on the Internet. In recent years, 
documents in widely varied areas arc increasingly represented in XML [1]. 
and numerous query languages [6] (hltp://www. w3c.org) have been also 
proposed, XML documents that contain security-sensitive information need 
to require an authorization before being available for retrieval. 

XML documents (objecis) need to be available only for those user 
credentials (subjects) if they are authorized according to the authorization 
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policies (actions and permissions). The dclcrminalion incihods for users 
access authorization can be represented as quadruple {subject, object, action, 
permission). The determination therefore is simply to match a bitmap mask 
(representing a user’s request) with an authorization bitmap index 
(representing authorization policies) to obtain the quadruple (subject, object, 
action, permission). The determination for access authorization is 
conceptually simple, but it yet accelerates the query process time. Most 
methods we know for access authorization arc not satisfactorily fast. It is 
partly because the access control requires the overhead in addition to the time 
required for query processing, and partly because the powerful expression of 
authorization policies makes it uneasy to make fast a determination. The 
propagation of subjects and objects is naturally to be evaluated at run time of 
authorization. 

Consider the following examples that motivate our research. 

Example 1.1: In database systems, an access authorization is first 

checked, and followed by query processing. Assume that a user <u01> 
requests to read the XML element <^>. What if the XML clement <6i> is not 
available in the database? Of course, in this case, no checking for access 
authorization is necessary. Unless acquiring an authorization, the user cannot 
know the absence of what is requested. However, if the database system put 
access authorization together with query processing in one framework, this 
problem can be avoided. 

Example 1.2: Assume again that a user <u01> requests to read the XML 
element <ft>, and an authorization policy authorizes <r02> to read <0j>. If the 
user with the role <r02> requests <a>,the first determination on authorization 
is that <u01> cannot read the XML clement <6i>, However, if the authority of 
<r02> is propagated to <u01> (or subject propagation), and the access to < 0 j> 
is propagated to <6i> (or object propagation), then ihe determination becomes 
positive. Notice there are two types of propagation: subject propagation and 
object propagation. Such propagation, especially object propagation, is not 
efficiently considered at the time of access authorization. 

In this paper, we propose a bitmap-based authorization technique for 
XML document access control. The authorization policies arc encoded into 
bitmap indexes. User access requests are encoded into bitmap-masks. By 
applying bit-wise operations, authorization can be determined significantly 
fast. 

The contribution of this paper includes 1) the dual goals achieved for fast 
and secure accesses to XML document collections, and 2) early propagation 
of subjects and objects in bitmap indexes. 

This remainder of this paper is organized as follows: Section 2 describes 
related literatures. Section 3 reviews the preliminaries regarding XML and 
bitmap indexing techniques and the model of access control. Section 4 
describes the technique of bitmap indexing. Early propagation of subjects 
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and objects is discusse<l. Section 5 describes the access control method in 
the authorization bitmap index using bit-wise operations. Section 6 describes 
experimental evaluation. Finally, We conclude our work in Section 7, 



2. RELATED WORK 

In this section, we describe bitmap indexing techniques and access control 
techniques. 

The collection of bitmaps in a bitmap index forms a 2-dimensional bit 
matrix [5], In this paper, we apply the bitmap indexing techniques to security 
management. Bit-wise operations developed in the earlier work will also be 
generalized to the multi-dimensional bit matrix context. 

Several access control policies are devised for controlling access to 
information and databases [8,10]. Proposed arc the closed policy and the 
flexible open policy. When a system imposes a specific policy on users, the 
users can work on the confines imposed by the policy [4]. Multiple access 
control policies within a single system are enforced, derived, and resolved if 
any conflicts [10]. Specification of negative authorizations can be stated for 
accesses to be denied [3], 

Numerous conflict resolution policies have been developed. Some of 
those policies arc dcnial-takc-prcccdcnce [3], most-specific-take precedence 
[7], most- specific policy together with the concept of strong and weak 
authorizations [3], and explicit-precedence policies [11]. 



3. PRELIMINARIES 

In this section, we introduce XML documents briefly, and bitmap 
indexing for XML documents. 

Each document {d) in an XML document collection D is represented in 
XML. So, d contains one or more words (w) that arc associated with XML- 
element paths (p). For example, consider Figure 3,1, The XML-element 
path order/item/desc has a value food in the document, while order has 
“International purchase" in it. An XML-element path is a sequence of XML 
elements from the top to the node containing content using XPath [13]. A 
collection of XML documents is a set of the triplets (d,p, w). 

Each such document (d, p,w) con be encoded into a bitmap. A bitmap is 
defined as a two-dimensional set of bits representing the existence of a pair 
ip, w) in d. An example of XML documents is Figure 3.1. 

In addition, one of XML documents we consider in this section is an 
authorization policy. This paper docs not aim to propose a new model for 
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aulhorizalion policies, but employ the previous work by Damiani and el al 
[8] to represent authorization policies uniformly together with XML 
documents like order.xml. An authorization policy specifies the determination 
of user accesses {subject) lo XML documents {object). Objects arc XML 
documents. A credential of a subject is user id (uid) or role id (rid) accessed 
through a specific ip address. An authorization policy is a specification that 
permits positively (or grants) or negatively (or denies) an action of a subject 
on an object. Objects (or XML documents) are hierarchically organized, and 
broadly speaking they arc widely distributed as stated by using XLink as 
shown in Figure 3.1. Similarly, subjects (or users and ip addresses) are 
hierarchically organized as shown in Figure 3.3. and somehow distributed. 



<?lfW WSHMs'VO' ?> 

xinms. tihks'nQ) tf . /xlir* * 

<orOer>fntefri€Wrtal purchase 

<desc»foocl<Ato5C> 

<pnce>9 89<^ce> 

Mtem> 

iU**a*>cO'p4aver 

<<Mc>applarvc«<Aj»6c> 

<03tar>wMt»<^cctor> 

<<}u9n1ity>2<quan lly:* 

<pnce>49 00<rprte> 

<i^ego Meni_kt«’a(r cns'price*> 

<ofter> 

<Drice> <sum item.ltfs’aiT computBs*’* ^l«*<9iantity arg2«*(Tice* /> <^Ktee» 
<ierm>Val 4 terms<^ami> 

<hHe> 

<desi>Caise<^eai> 

<T5e90> 

Rex SL, Lafayette, LA 70S04 
«HAkicc8Kv hreMcpAWay«B»iMneci 
«iik:»; from:*re>not8* to='lo«ri* actu8le='GrRequesr rx/iMKerv> 

<rtr<tet> 



Figure S.l. Coder Example in XML 



Figure 3.2 exemplifies an authorization policy file. Because of 
hierarchical organization of subjects and objects. XML elements, subject and 
object, specify the attribute propaQation. There arc three propagation direction: 
1) no propagation. 2) downward propagation, and 3) upward propagation. 
Possible propagation of subjects is stated as the partial ordering in Figure 3.3. 
For example, the second aulhorizalion. a2, specifies a downward propagation 
of subject, user of rid. The same authority for the subject user can be effective 
for other users. u33, u15, u7. and u19, as shown in Figure 3,3. On the other 
hand, the fifth authorization, a5. specifies an upward propagation of object, 
order/delivery. The same access effect on the XML path, order/delivery, can be 
effective for its super element, order. 
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<authonzdkyi_1ist> 

<auinori»lbn eid*''ar> 

<$ub|Kt prop99abor>s'r><uia>u21<;ud> <ui3>u33</uiO><^uttec(> 

<ot)i^ pron9aib/>B''F*>ofder inMirderAiepri ordef zmlfQrder/0elv6f^abj«a> 
<ac1<or>feacK'3Clion> 

<pe'nii«$)&n>gr9nl$0</ perm8Sbn> 

</auiNxi2afion> 

<9UtWi2allon aid«'a2'> 

^subject propd 9 aVon»'dDMin‘><ria>u 8 er<^><^iC)|eci> 

<0DjM prODSgMor«T*>Ofd«r xiNferd»n^l<m|3] orderj(rnlAxMrMgoyofM2)iV^e<^ob(^ 
<aclioa>read wrte</K<ion> 

< perm«$l 0 ii> 9 nrKed</ pemii»lon> 

<^uinotGutk^> 

<aut^ontation ail='a3'> 

<9u^ect Dfopd9aNoris*P’><oU>$ngineef«/uij></9Ut)jec(> 

<oD|M p(9p8gabQn**<3cwri*>onJe' xinl^onj»r</citj6Ct> 

<aclK>n ad)vat>on«T>ra3d wnto<^lio(P 

< permiMion^granM^ pemiisaion> 

4auinori2atlon> 

<autr«nul)on aid-'94‘> 

<subiect pro|ugatlori^up*><fU>comp_statl<^rU><^9ubtecl> 

<object pn>pagalior=’dcw'i'’Ofilet nnVDn]eifit9m<;^ct)tecl> 

<ac(bn>read^c(i9n> 

c parmissicn axclucN.by^'ip* ^’33.1 29 20.Mu'>0anied«/ pamissiorv> 

</8UlN3nza»&n> 

<aulhofi:ation aid-'aS^ 

<8ub|ect propagaten«'rv<ud>saies</uiQx/au^ct> 

<objM propag S4tfis*up*>order.x(nl'op0eryd«lrir9'y</ot^> 

<action>fesd</acliw> 

< CMrm«$«ri>4«nied<^ pennBa)en> 

<^ulbor«ttO"> 
cauthcr^abon ail=‘a6'> 

<9ub)ecr proMgabofis*<foiMi‘><rid>c9'np.$tan</^></sub^(> 

«obj^ pfDf»galions^kwri*>onjer.unVbrd8f^Q^offer<oti|ect> 

<actlon aclw«tion»*T’>wrtt</»iofl> 

< Mrrnjs9ion>deflklad</ parm«sion> 

<^SirtrK3r«Aon> 

</auinofizabon,l$t> 



Figure 3.2. XML Aulhoriiaiion Policies 



The access control model adapted from [8] in this paper makes use of 
authorization policies (j, o, j, m), Having a request o\ <a) posed to XML 
document >v)» che determination using the authorization policy is<j', o\ 
a, m) if^’ and o* are matched' with .v and o respectively, where m denotes 
either grant or denial. If the permission is granted, the answer becomes {d,pt 
w) if is matched with p. This paper describes the method of high*speed 
determining an authorization for an access to XML documents. Generating 
answers is not within the scope of this paper. 



By match we mean they are (he same, or one is contained in another, by propagation of 
subject and object. 
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4. BITMAP INDEXING 

In this seclion, we propose the bitmap indexing technique that can speed 
up the delerminalion process for access aulhorizalion and associate with 
query processing. Authorization policies are first encoded into a bitmap 
index. The bitmap index represents the existence of pairs (XML path, value) 
that are specified in the authorization policy file in Figure3,2. Consider a 
request posed to a collection of XML documents. A secured information 
system should have the both capabilities of query processing and security 
management. Depending upon equipping these capabilities, there may be 
three broad approaches: 

Decoupled authorization . Having the two capabilities separately, a naive 
approach is to obtain the determination from the security management by 
matching with the request. Once matched, the request is performed by the 
query processing and so applied to the XML document collection. 

Tightly coupled authorization . The query processing and the security 
management are coupled tightly together. Once one capability is performed, 
the other capability can be achieved with paying no extra effort. This 
approach has drawbacks such as less flexibility in modification and 
inefficiency in extendibility. 

Pipelined authorization . Outcome of security management is pipelined 
with query processing. Only appropriate documents authorized from the 
security management are further processed for query processing. This paper 
focuses on the pipelined but yet high*speed authorization. 

The pipelined authorization is proposed to conduct the following steps: 1} 
Parsing an authorization policy file, 2) Encoding the information about the 
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authorization policies into bitmaps. 3) Encoding the XML path of an XML 
document collection, 4) Early propagating both subjects and objects. What 
follows in the subsections includes our proposed methods of encoding and 
early propagation. We also assume that a collection of XML documents has 
been encoded into BitCube (14). Briefly speaking, similar to the construction 
method of an authorization bitmap index, the BitCube is constructed for 
XML documents, setting 1 ’s and O’s in bitmaps, 

4.1 Encoding into Bitmaps 

The following files arc encoded into bitmaps: Authorization policy file, 
XML document collection, and user requests. User requests are encoded into 
bit“inask dynamically at run-time, while authorization policies and XML 
documents arc once encoded into bitmap indexes at compile-time. 

An authorization policy describes who (subject) has an authority 
(permission) of a specific action (action) on XML documents (objects). 
Among many XML elements and attributes as shown in Figure 3.2, 
minimum but yet useful information is considered. Such information is 
illustrated in Figure 4.1: (a) is a list of XML paths which is minimum but yet 
useful from Figure 3.2, and (b) is a list of values that arc associated with the 
paths listed in (a). For example, the XML path, subject/uid has values, 
engineer, sales, u15, u19, u7, u21, and u33. Each pair (XML path, value) 
indicates a position of the bits in the bitmap index. The pair (subject/uid, 
engineer) = [0,2] indicates the first bit column of the bitmap index shown in 
Figure 4. 1(c). 

Similarly, a temporary XML bitmap index is created for the XML 
document order .xml shown in Figure 3.1 together with other two documents, 
order2.xml and order3.xml. By “temporary" bitmap index, we mean that this 
bitmap index is to be propagated to represent possible authorizations further. 
Possible authorizations are derived from the attribute descriptions, e.g., 
propagation attributes with values. The early propagation is discussed in the 
next subsection. Figure 4.2 (a) is a list of XML paths, each of which is a 
pointer to a bit column in the temporary XML bitmap index in (b). 

4.2 Early Propagation 

There arc two early propagations considered in this section: 1) subject 
early propagation and 2) object early propagation. The authority for a 
specific object or subject can be propagated. The propagation of objects or 
subjects is characterized by the direction of propagations, or by the rate of 
propagations. The propagation attribute associated with subjects or objects can 
have values of false (“F"), upwards (“up") or downwards (“down"), each of 
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which indicates the direction of propagation. In the following subsections, 
subject early propagation, object early propagation, and the degree of 
propagations will be discussed. 
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Figure 4 J. Auihorizaiion B cl map Index 



4.2.1 Early Propagation of Subject 

The value for the propagation attribute in Figure 3.2 indicates the 
direction of propagation. Hie propagation is available along the partial 
ordering hierarchy in Figure 3,3. For cxajnple, the subjetd element of the first 
authorization policy has the propagation attribute value of “F.” which means 
no propagation is allowed. But, in the second authorization policy, the subject 
element has the value “user” for the rid sub-eletncnt and the value “down” for 
the propagation attribute. What it jncans to be is to propagate the authority of 
rid user down to sub-subjects. The sub-subjects in the partial ordering 
hierarchy of Figure 3,3 are comp.staff, u15, u19, u7, and u33. The authority of 
user is propagated tocomp_staff, u15, u19, u7,and u33, as well. 

As the authorization policy file is parsed, this propagation information is 
obtained and exploited to early propagate in the authorization bitjnap index. 
The initial bitmap index in Figure 4.1(c) is evolved to the bitmap index as 
shown in Figure 4.3. The bits for subject arc early propagated. 
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(b) 



Notice that actual files for ordcr2 xml and orderyxml are omitted in this paper 



Figure 4. 2. A Temporary B i imap Index for X M L Doc umen is 



4.2.2 Early Propagation of Object 

The aulhoriiy on an object is propagated onto appropriate objects, but the 
temporary bitmap of XML documents is exploited to early propagate objects. 
The temporary bitmap index in Figure 4.2 represents the existence of pairs 
(XML path, value) in each doeument, but docs not make the authorities 
'‘fully” available to any legal authorized users. Notiee that the legally 
authorized users are obtained by the early propagation of subjects. To 
overcome this incomplete information, the early propagation of objects is 
developed. 

The authorization on XML documents is burgeoning to serve in high- 
speed with secured XML documents. For example, an XML document in 
Figure 3.1 is encoded in the temporary bitmap index as shown in Figure 4,2. 
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Figure 4J. Authorization Bitmap Index after Subject Early Propagation 
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This temporary bitmap index is then propagated downward or upward 
according to the authorization policy. The authorization policy bitmap index 
is burgeoning into Figure 4.4, In the authorization bitmap on top of the 
figure, the first two rows in the bitmap index arc pipelined with the 
temporary bitmap indexes on the bottom (thru the labels cl and c2). Only the 
limited information but the one actually requested is available. For example, 
if the document order. xml is requested, only the bits, 1, 6, and 17. i.e.. the 
content oforder/jtem[1], order/item[2j. and order/delivery are provided. However, 
by the third authorization policy, although order.xml/order is requested, 
because the propagation is allowed, the authority on that object can be 
propagated downward to all of its sub*clemcnts. The third authorization, 
authorizations is pipelined with the temporary bitmap index through the label 
c3. If order.xml/order is requested, then not only the content requested but also 
all propagated contents, order/ilem[1j/color, order/nego/offer[2]/price, 
order/nego/offer[2]/term[1), and order/nego/offer[2j/term[2j become available. 




Figure 4.4. Burgeoning Example of Auihorizalion Policy Bitmap Index 
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5. ACCESS CONTROL IN AUTHORIZATION 
BITMAP INDEX 

One of the advantages exploiting a bitmap index is the significant 
improvement in operation evaluation and query processing. We consider bit- 
wise operations for a bitmap index. Bit-wise operations are AND, OR, and 
XOR. Consider a user request. A user request is encoded into a bitmap mask, 
q. using the same XML paths and values as the way encoding XML 
documents and authorization policies. Also, consider the burgeoned 
Authorization Policy Bitmap Index, ot in short. Broadly speaking, the naive 
approach for access control is as follows: 

The bitmap mask is AND -ed with the authorization policy bitmap index. If 
the outcome is the same as the original bitmap ma.sk, then the subject 
becomes authorized to access. 

The bitmap ma.sk is XOR-ed with each document in the BitCube. If the 
size of the outcome is 0, then the object can be accessible. 

Having bit-wise operations with the Authorization Policy Bitmap Index, 
we discuss a pipelined processing for secure access control and for query 
answering. The burgeoned Authorization Policy Bitmap Index represents 
authorization policies together with corresponding document indexes, but not 
all the bits in the Authorization Policy Bitmap Index should be equally 
treated. The following subjection describes how differently to treat the bits, 

5.1 Evaluation Scheme of Authorization Policy Bitmap 
Index 

Consider Figure 5.1, which is simplified version of a burgeoned 
Authorization Policy Bitmap Index, a. There are six groups of bits, the bits 
for pid, uid, rid, action, permission, and object, and those bits arc further 
grouped into five bit-regions, the region for (a), (b), (c), (d) and (e). Those 
six bit groups arc classified based on the specification of authorization 
policies, while those five bit-regions arc classified based on the evaluation of 
XML dements in authorization policies. 

The bit-region (a) in Figure 5,1 is to check the general information about 
authorization policy, which can be used for conflict resolution, identification 
of policies, or query types. The evaluation of this region is an exact match 
based on the XOR operation: | or XOR q\ “ 0, where ii| denotes the number of 

I s in X. 

The bit-region (b) in the figure is to check if a user is matched any one in 
uid or rid for its credential. That is, a query bitmap ma.sk q is contained in the 
Authorization Policy Bitmap Index or. This containment is performed based 
on the AND operation: (or AND 9) * 9. Similarly, the bit-regions (c) and (c) 
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can be performed. However, theses arc evaluated separately and all 
evaluations should be satisfied before pipelining further. 





(a) (b) (c) (d) (e) 

Figure 5.1. Bli-Region-based Evaluation 



The bit-region (d) in the figure is to check the conditional determination 
of permission. Reeall that permission is either granted or denied, and it can 
be conditionally by stating “excluded.by,” e.g., ip address. For example, in the 
authorization a4 in Figure 3.3, from any ip address unless otherwise a 
credential user can access an object. If the bit for the excluded_by attribute is 
set to 1. then the rest bits of this region is evaluated by the XOR operation: 
(a XOR q) = q. If not. it is evaluated by the AND operation: ANO q ) » q. 

The outcome of the evaluation of the bit-region (b). (c) and (e) is 
pipelined with the evaluation of the bit-region (d). If finally the bit-region (d) 
is successfully evaluated, then the BitCube is accessed to further comparison 
such as selection condition (q2 in Figure 5,2). 

Example 5.1: As an example, consider three requests in Figure 5.2, The 
request ql is encoded into the bitmap mask: 0000 1 000000& 1 0&1 000 
0000000000000000, where & denotes the delimiter between the bit- 
group (b), (c) and (e). Of course, the bit-group (d) is not given by a request, 
but will be determined by an authorization. This mask is contained in the 
authorizalion2 of the Authorization Policy Bitmap Index in Figure 4.4, Thru 
the label c2. the outcome is pipelined to the burgeoned Index in Figure 4.4, 
However, none of these two authorization policies contain 10000000000 
000000000, meaning that the first bit for object /order is not available in 
any XML files labeled by c2. Therefore, nothing is returned. Although the 
request is allowed, no matches are returned. 

Example 5.2: Consider the second request q2. The bitmap mask of q2 is 
00001 000000&01&000000000001 00000000. The 
authorization2 and aulhorization6 contain the user credential because both 
authorizations authorize for the write action. However, the evaluation of the 
bit- group (e) returns the objects of all three files. In those files, object 
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requested is further evaluated for the comparison, say check for the word 
“Valid term. " will be done in the BilCubc, 

Example 5.3: Again, in Figure 5.2. consider the request q3. Its bitmap 
maskis: 00001000100&01&0100000000000000110 0. The 
credential of u7 is contained in the authorization!. authorization4, and 
authorization6. In this case, ordcr.xml, order2,xml and order3.xmi arc 
partially accessed, but authorizadon4 allows more information than the other 
two. If there exists any type of conflicts, conflict resolutions should be 
considered. The conflict resolution is not within the scope of this paper 
either. 




(q2) Uid u7 requests lo wale on the documents 
whose negoLiation term )s valid. 



Figure 5.2. Example of Requests 



6. CONCLUSION 

We proposed in this paper a new technique for secure but fast 
authorization for accesses to XML document collections. The techniques for 
encoding both authorization policies and XML documents, and pipelining 
them together in a bitmap index have been developed. The contribution of 
this paper includes 1) the dual goals achieved for fast and secure 
authorizations for accesses to XML document collections, and 2) early 
propagation of subjects and objects in bitmap indexes. 

Our work can be applied to variously wide areas of information 
management. Pipelining manipulation of two semantically different 
information sources is possible. Bit-wise operations on bitmap indexes arc 
useful to improve the evaluation of information processing. 

Some of our future work includes 1) conflict resolution that can be 
performed in a bitmap index, and 2) incremental indexing that can be 
adaptive and scalable to the additions and deletions ofXML documents. 
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Abstract In Brewer and Nash (BN) presented a fascinating idea, called 

Chinese wall security policy model, for commercial security. Their idea 
was based on the analysis of the notion, Conflict of Interest binary 
Relation (CIR), Unfortunately, their formalization did not fully catch 
the appropriate properties of CIR. In this paper, we present a theory 
based on granulation that has captured the essence of BN's intuitive 
idea. The results are more than the Chinese wall models: Malicious 
Trojan horses in certain DAC Model (discretionary access control) can 
be controlled or confined. 

Keywords: Simple Chinese Wall Security policy, Agressive(Strong) Chinese Wall 
Security policy, binary relation, conflict of interesLs, equivlaenee rela- 
tion. 



1. Introduction 

Recent developments, such as cCommcrcc and homeland security, have 
prompted us to re-visit the idea of Chinese Wall Security Policy (CWSP) 
model. “The Chinese wall policy combines commercial discretion with 
legally enforceable mandatory controls perhaps, as significant to the 
financial world as Bcll-LaPadula's policies arc to the military,” This is an 
assertion made by Brewer and Nash; see the abstract of |2]. We believe 
it is still valid. 

In 1989. Brewer and Nash(BN) proposed a very intriguing commercial 
security model - called Chinese Wall Security PoIicy(CWSP) Model 
|2|. Intuitively, the essential idea was to build a family of impenetrable 
walls, called Chinese walls, among the dataset of competing companies. 
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No data that are in conflict can be stored in the same side of Chinese 
walls. BN’s analysis of the security problem were fascinating and is still 
valid; the only unfortunate part is their mathematical model has not 
fully captured their analysis. It was ba.scd on 

■ The incorrect assumption that corporate data can be partitioned 
(decomposed) into mutually disjoin conflict of interest classes (CIR- 
classes); such a disjoint collection is called a partition in mathe- 
matics; see e.g.. [3]. 

■ Unfortunately, CIR-classes seldom disjoints; they do overlap, and 
hence Brewer and Nash theory does not held well. 

In the same year at 1989 Aerospace Computer Security Application Con- 
ference. we reported BN's errors, and presented a modified model, called 
an aggressive Chinese Wall Security Policy model (ACWSP) [14|, In 
that paper, we did not bring out the essential strength of ACWSP 
model. A relatively inactive decade has passed; only few papers, which 
are. however, still based on the same erroneous assumptions, appeared. 
By refining the idea of ACWSP, in this paper, we have successfully 
captured the intuitive intention of BN "theory," 

The theory that we are presenting is based on the development of a 
novel computing methodology. We observed that 

■ The collection of CIR-classes form a binary granulation, even though 
not a partition. 

Intuitively a binary granulation is a collection of subsets, whose “core" 
or “centers" form a partition; see the main text below. In terms of bi- 
nary granulation, we recapture the spirit of Chinese wall security policy 
(CWSP) model. The results are more than that; with mild assump- 
tions, we can actually confine malicious Trojan horses on DAC model 
{Discretionary Access Control). Sensitive information will nrn flow into 
"enemy" hands, only flow among "friends," 

2. An Analysis of C until cts( CIR) 

Before we launch on the new theory, we recall some analysis from [14]: 
Conflict of Interests is a binary Relation (CIR) among corporations; it 
can be used to regulate the information flows among corporations. 

2.1. Is CIR an equivalence Relation? 

In BN-theory. CIR were assumed to be an equivalence relation erro- 
neously, in other words, 0 were partitioned (decomposed) into mutu- 
ally disjoint CIR-classes (conflict of interest classes) However, "conflict 
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of interests/' in normal daily usage, can not be transitive, at least not 
universally transitive. 

Let us recall the exiunple from [14]: The following two statements, 
at least, during the cold war period were valid. 

USA was in txild war with USSR, and 

USSR was in cold war with UK. 

Could we conclude from these two assertions that 

USA was in cold war with USSR. 

This is rather absurd. Of course,in cold wi^ with, is only an example, 
nevertheless, it does clearly indicate that CIR can not, in general, be 
transitive. So an ecjui valence relation, which is reflexive, symmetric and 
transitive, is not a proper mathematical model for CIR. 

2.2. A Set of Axioms for Secure CIR 

In this section, we re-visit the Aggressive Chinese Wall Security Pol- 
icy (AC WSP> Model [14]. We recall (with some modifications) the ax- 
ioms for the binary relation, CIR C 0 x O: 

CIR-1: CIR is symmetric. 

CIR-2: CIR is anti -reflexive. 

CIR -3: CIR is anti-transitive. 

Some observations may be helpful: CIR-2 is necessary, since each com- 
pany cannot conflict to itself. CIR-1 is always valid: If company A is in 
conflicts with B, B is certainly in conflicts with A. CIR-3 is imposed, be- 
cause it implicitly required in BN's notion of Chinese walls (Section 3.1). 

To stress its importancy, a new property will be explicitly listed as i\n 
“axiom", though it is implied by the others: Let Ecir be the induced 
equivalence relation of CIR(See Section 3). 

CIR-4: The granulation of CIR imd partition of EciR compati- 
ble, in the sense that each CIR-class (or in geometric term, CIR- 
neighborhood) is a union of EciR •6qui valence classes. (Sec Propo- 
sition 2 of Section 3) 

Intuitively, this is significant!; previously we have placed Chinese walls 
on the “boundaries" of CIR-classes in[14]. But each of these boundaries 
is “one-sided;" its complement is not an union of CIR-cla.sses. But CIR-4 
implies that that such boundaries are “two-sided;" Because the “interior 
and exterior" iMS both unions of Ec/n-equi valence classes. 
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CIR-5 (lAR): If we inlcrpret CIR as “is an adversary of'-rclation, then 
ihc complement is "is an ally of -relation (lAR), lAR is an equiv- 
alence relation, by Corollary 4 of Section 4. 

Theorem 2.2. If R is a symmetric and anti-reflexive and anti-transitive 
binary relation, its complement R' is an equivalence relation. In partic- 
ular, lAR. as the the complement of CIR. is an equivalence relation. 

Proof: Let [X]jar lAR-equivalence class containing X. Then, we 

note that € [X]jafi. Hence their complements 

are equal, so we have 

Corollary CIRx ® CIRy 'i Y € In other words, the infor- 
mation of any object in can flow freely among themselves 

3. Chinese Wall Security Policies 

BN proposed Chinese wall security policy to capture certain requirments 
in UK's financial sector, A decade later, we beleive their anlaysis is still 
useful and valid (but not their mathematical model). In this section, 
we will re-visit their requirements, namely. Chinese Wall Security Policy 
(CWSP), 

3.1. Simple Chinese Wall Security Policy 

We will continue on BN's notations: 0 is the set of all objects (corporate 
data), X.Y. and Z are objects in 0. 

1. BN-Version : “people are only allowed access to information which 

is not held to conflict with any other information that they already 
possess." See [2], Section "Simple Security", p, 207. 

We will rephrese it mathemtically: 

2. SCWSP Simple Chinese Wall Security Policy means 

There is no DIF from X to Y . if and only if {X, Y) € CIR, 

where DIF (direct information flows) means the agent y (who han- 
dles T) read the data in F(and may make a copy in 10. 

In terms of D AC (Deseret ionary Acess Model) langauge, we should say x 
grants y a read-access right; and y read the data and make a copy in Y 
(making copy is permissible, even in streit DAC model; sec [23]) 

Please note the necessary-and-sufficient-condition type of statements. 
BN's rules allow an agent to read any two sets of data as long as they 
are not CIR. So we havw the dual of SCWSP: 
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3. Doal-SCWSP Daal-SCWSP is equivalent to CWSP, but opposite 
View: 

There is DIF from X to F . if and only if (X, Y) ^ CJR. 

3.2. Agressive Chinese Wall Security Policy 
(ACWSP) 

First, let us state a convention, some definitions and comments: 

Convention : The symbol, CIR. always denotes a binary relation that 
satisfies the axioms. 

Definition CIF (composite information flow) from X to K is a sequence 
of DIFs (direct information flows), which starts from X and end 
at Y : 

X » Xo — » Xn * F, 

where each " — is a DIF, 

Caution : We should stress here that simple security policy only regu- 
late DIF’s. Note that even if we are assured that there is no DIF 
from X to Y, it is conceivable some clever CIFs may send infor- 
mation, say from X, via Z. to Y. In other words, two innocent 
DIFs from X — ► Z and Z — » Y could compose into a malicious 
CIF, X — ^ Z — ♦ K 

Such CIFs have been identified as Trojan hon^es. Confining the mali- 
cious Trojan horses is actually the essence of the main contribution of 

ACWSP-model. 

ACWSP Agressive (Strong) Chinese Wall Security policy. 

There is no CIF from X to Y, if and only if (X, Y) 6 CIR. 

Chinese Wall Theorem. Under the assumption that CIR meets the 
axioms (anti -reflexive, symmetric, and anti-transitive), 

ACWSP ^ SCWSP 

Proof: First, let us note the following FACTs from Section ?? 



FACT 1. CIR and IAR(*'is ally with") are complement to each other, 
FACT 2. lAR is an equivalence relation. 
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We need some notations. Let X be an object (a company data) of 0. 

Let 

ClRx (= [Y 1 {X,Y) € cm } be the OR-class of X and 

(= {Y I (X,Y) € lAR }), or simply [XJ. lAR-equivalencc 
class of X 

Lei X be an object (a company data) of 0. Lei 

ClRx (= lY I (XT) e CIR } be the CIR-class of X and 

[X\iAH (= {Y 1 (XT) € lAR }), orsimply [X]. lAR-cquivalence 
class of.Y 

To prove this theorem, we need to establish Ihe following Agressive(stron|») 
Chinese wall security policy for the given Simple CWSP: 

There is no CIF from X lo F (X, Y) e CIR. 

We will use indirecl proof, so by assuming to Ihe contrary, we have two 
conditions: 

1, There is a sequence of DIFs (direct information flows) 

X = Xo — Xi — . — Xn = y. 

2. K € ClRx- 

Our task is lo derive a coniradiclion: we will prove il by malhematical 
induction. 

First, the initial assertion: 

If X = Xo — * Xi is a DIF, then ClRx = ClRx^ and 
[X]/AR = (Xi]Mft 

To prove this assertion, note that X], receiving information from X. 
cannol be in CIRx' Hence, must be in its complement, lhal is, 

Xi € 1X[/4A. 

Since lAR an equivalence relation (FACT 2), we have 
[X]jAH- 

By the fad that they are Ihe complements, we have 

ClRx = ClRx,. 

So ihe initial assertion is proved. 
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Next, we consider the induction case. The arguments are essentially 
the same. By induction assumption, we have 

= \X,\,AR and CIRx = C!Rx,- 

Next, consider the DIF. Xj — ► -^(j+i)' 

Since + receiving information from Xy, cannot be in ClRx ■ By 
the FACT 2 again, ^ 

Xj+i € = lX)//ift. 

By the FACTs that lAR is im equivalence and CIR is its complement, 
we have 

CIRx^ClRx,,,. 

This completes the induction proof. In particular 
€ \x\iAR, 

This is contrary to one of the assumptions (Item 3.2). We have pmved 
the strong Chinese wall security policy. That is. we have proved: SCWSP 
T— t* ACWSP. The converse is obvious. 

4. DAC Models and Trojan Horses 

In this section, we take the DAC view on ACSWP model. If the agent 
X explicitly denies the read access to y, then we say 

The information flow from X to F is denied, or equivalently. 

No direct /nformation Flow (NIF) from X to F is permitted, 

If the information flows between objects lue regulated by NIF, we say 
0 is a flow oriented explicitly denied DAC model. NIF defines a Binary 
relation (NIFR) among all objects. 

Delinition : A Composite Information Flow from X to F is called a 
malicious Trojan horse, if NIF from X to F is the given require- 
ment. 

Trojan Hurse Theorem. If NIFR is anti-reflexive, .symmetric and 
anti-transitive, then the following three assertions are equivalent 

Malicious Trojan horses from X to Y may not occur 

4 — DIF from X to F may not occur 

(X. F) € NIFR. 

NIFR is a DAC form of CIR, so this theorem follows immediate from 
Chinese wall theorem. 
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5. Some New Views of ACWSP 

The new observation on CIR gives a new insight to the CWSP-model, 
Here arc the new views of theorems in |14] and [2). 

THEOREM I. Once a agent Si has accessed an object the only 
other objects Ok accessible by Si is inside the allied dataset of Oj, which 
is the outside of ClRo,- 

THEOREM 2. The minimum number of agents which allow every ob- 
ject to be accessed by at least one agent is n. where n is the number of 
valence classes. 



THEOREM 3. The flow of unsanitized information is confined to its 
allied dataset; sanitized information may, however, flow freely through 
the system. 

6. Conclusions 

The intuitive idea behind Brewer and Nash theory is useful for commer- 
cial security. By the new demands in eCommerce, as well as homeland 
security, we re-visited the BN-theory. In [19]. we fuzzify the ACWSP 
model to make it more susceptible to uncertainty. In this paper, we 
refine ACWSP model by the new development of granular computing. 
The results are somewhat surprising, we can confine the malicious Tro- 
jan horses. 

This paper realizes the BN's intend, however, it has more. From 
DAC’s view, the results are just the beginning; it shows that information 
flows analysis on DAC is no longer a hopless subject. More analysis will 
be reported in near future. 

Appendix: Granular Computing for CIR 

Trojan horses in DAC model have been the weakest point of DAC model. Implicitly, 
BN's CWSP is designed to handle that. Unfortunately, their idea of using partition 
is a bit naive. This paper indicates that granulation seems a right notion. In next 
few sections, the new methodology will be explained. 

1. Equivalence Relations and Partitions 

A poriiiion is a collection | ^ * 1. 2, , . of disjoint subsets whose union is V. 
This geometric notion defines naturally an algebraic notion, an equivalence relation, 
as follows: 



£sUj{(p, u) I p and ti are in A'j) 
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Thi^ equivalence relation is reflexive, symmetric and transitive. N/ is called an equiv- 
alence cla» in mathematics, Ii also has been referred to as an elementary set, a 
block, a granule [24].(10],(21). Conversely, an equivalence relation defines a partition; 
we skip the details. 

Algebraically, a natural generalization of an equivalence relation is a binary re- 
lation. Geometrically, a “common” generalization of a partition is a covering. Un- 
fortunately. a covering is not the geometric equivalence of a binary relation. The 
equivalent one is a more elaborate notion; see next subsection, 

2. Binary Relations and Granulations 

Let RCV^Ubsi binary relation. We will re-express R geometrically. 

Par each object p € V, we associate a subset (binary set. neighborhood, or class) 
NpCV defined by 

ATp - {u € U I (p>«) € Rj 

Np consists of all elements v that are related top by the binary relation R. Geometri- 
cally, /^pcaii be regarded as a neighborhood of pin the following sense; the points in 
Np are “near to” or “related to” p via /?. We will use binary neighborhood to remind 
us that algebraically, it is defined by a binary relation, while geometrically, it consists 
of points in proximity. Intuitively. Np l.s the “nearest” neighborhood of p. 

In BN-theory, CIR<lasses are actually CIR- neighborhood. Just to be compatible 
with literature. we will use QR-cla.sses; readers should be cautioned that they are 
actually neighborhoods, not equivalence clas.ses. 

To help visualize the situation, we will use geometric language, 

A binary granulation is an a.ssignment that assigns to each object p € 1^, a (po.ssibly 
empty) subset BpCU- 

We will refer to the collection, {Bp \ p € K}, a binary neighborhood system and 
each Bp as a binary neighborhood ofp € V . They are called a basic neighborhood 
and a basic neighborhood system respeaively in [16). Though the subset Bp sounds 
arbitrary, it can be regarded as a binary neighborhood Np of a binary relation, for all 
p. Formally, let us collect the comments into a 

PropoxUion. Binary relation, binary granulation, and binary neighborhood system 
are equivalent. 

In other words, given the map B (or the collection {Bp C t/ | p € V'}), there is a 
binary relation RCVxU such that Bp = Np and vice versa. So we will use the three 
terms interchangeably and denote all of them by B. The proof of the proposition is 
straight forward; we skip the details. 

In application, a binary neighborhood at p 

{v \ € B). 

is often assigned a descriptive name, called elementary concept (or an attribute value 
in database community). The collection C of all those elementary concepts is called 
the concept space (or attribute domain). Formally, we define 
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A granular siruciure consists of 4-iuple 

{V.V,B,C) 

where V is called the object space, U is the data space (V and U could be the same 
set), is a neighborhood system, and C is the concept space which consists of all the 
names of the fundamental neighborhoods of B. If 5 Is a binary neighborhood system 
(binary relation), then the 4 -tuple (V, U. B, O is caJled a hinaty ^ranulor structure. 

3. The Induced Partitions 

In [17, 18), T, Y. Lin observed that the binary granulation relation, 

B ; V — 2*' 

induced naturally a partition: 

Consider the collection 

I ur € 2^), caJled inverse image of tu under B. 

It is easy to verify that the collection forms a partition on V. We call it the induced 
partition of B, and denoted by Bq. 



The equivalence class, (plfp = B 1(0^), or simply write as (pj, is called the center 
or core of 



Proposition A The center |p| consists of all those points that have the same binary 
neighborhood Dp (“same" in the sense of set theory). 

Proposition 2. If 5 C K x is a symmetric binary relation, and is Its induced 
equivalence relation, then each ^-binary neighborhood is a union of £fl-equiv&knc^ 
classes. 

Proof: Let Bp be the binary neighborhood ofp. Let x € Bp, and assume i and y 
are i/&-equivalence. By definition of equivalence in Eb, they have the same neigh- 
borhood, Bt. — Bp- By the symmetry of j € Bp implies p € B* = Bp, 2 nd hence 
y ^ Bp. In other words, both i and y are in Bp. Since y is arbitrary, this proves 
|r) C Bp, that is Bp contains the equivalence class \x] of its member i. QED 



This proposition is one of the main technical results that have a strong impact on 
Chinese Walls. The condition of symmetry in this proposition is needed: In the 
oringal version examples were given; for space consideration; we skip the examples. 

4. The Complement of a Binary Relation 

First some definitions 

A symmetric binary reluiion B is a binary relation such that for every (U|V) € B 
implies (v,u) € B. 

A binary relation B i.s ami~reJ1exive. if B is non-empty and no pair i.s In B. 
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A binary relation B is anihiransUtve, it B is non-empiy and if (ii,v) belongs lo B 
implies that tor all w eiiher (u, or (uf,v) belongs to B. 

0* as V X y ^ which is the complement set of B, defines the complement binary 
relation (CBR). 

ProposiT/on 3. If B is symmetric, anti -reflexive and anti -symmetric, then the comple- 
ment binary relation B' i.s an equivalence relation. 

Proof: B is anti-reflexive, so the diagonal set is contained m the complement, that is, 
B' is reflexive. We will prove by indirect method: Assume to the contrary that (ti.ur) 
and are in B* ^nd its composition (u, v) were not (that is, (ii.v) € S). By 

anti-transitivity of 5, we should either and (w,v) belong to B: a contradiction. 
So the assumption (i*,v) € B is incoireci; This leads to (u,v) € B’)-, QED 

CoroUarv 4. It B is symmetric, anti-reflexive and anti -transitive, then B'is the in- 
duced equivalence relation Eg. 

Proof: Let v ^ V and Bv be its binary neighborhood. First we want to prove 
B' £ Eq\ That means we need to show that for any which is B'-equIvalent v, 
is £s>equi valent to v, that is. By. = Bu 

First, we will show B» C B*; Note thai (u,v) € B\ by assumption. Let p 
be a point in the Bv» that is. (ti,p) € B. Then, by anti-transitive and symmetry, 
(y,p) belong to B (otherwise. (u,v) € B, which is absurd). That is. p Is in the 
neighborhood of ti. So we have proved that C 

Let q € plays the role as p, by a similar arguments, We can show that 
Bu C Bv> So we have proved u and v have the same neighborhood, that is, 
flu =5 flu- This conclude the proof: B' C £fl. 

Second, we will prove the reverse inclusion Eg C d': Note that (w,v) € Eg 
implies Bii * Bv p be a poini in Bv = Bn, that is, boih (u,p) and (p,v) be- 
long to B. By anti-transjtiviiy and symmetric, («,v) belongs to B'. This proves the 
Corollary, QED 
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Abstracl We 5Jiow how specificaiions of roIe^bK^sed access control <RBAC) and 
temporal roIc*based access control (TRBAC) policies in a logic lan- 
guage ma> be used in pmcikt/i implementations of access control poli- 
cies for protecting the information in SQL databases from unauthorized 
retrieval and update requests. Performance results for an implementa- 
tion of a variety of RBAC policies for protecting an SQL databases and 
some optimization methods that may be ased in implementations are 
described. 

Keywords: RBAC, SQL, Internet Database, 

1. Introduction 

The protection of SQL databases from unauthorized access requests 
has long been recognized xs being imporlani. However. SQL standards 
and SQL products have hitherto included only limited options for ex- 
pressing the protection requirements for the information contained in 
SQL databases. 

In the SQL2 standard [11], the security-specific language features are 
restricted to simple GRANT and REVOKE statements. The GRANT- 
REVOKE model enables a security administrator (SA) to represent only 
a small subset of the access control policies that arc needed in practice 
[4]. For instance, SQL does not enable conditional limitations on the use 
of a granted privilege to be specified [4]. Of course, views may also be 
used to help to control access to information, but combining views and 
GRANT-REVOKE statements complicates the expression of an access 
policy. 
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In the proposed SQL: 1999 standard, language features for expressing 
RBAC policies are included. However, the proposals are again limited. 
For instance, SQL: 1999 does not include features for representing tem- 
poral authorization policies. Although implementors of SQL database 
systems may offer more sophisticated options than those included in the 
SQL: 1999 standard, current systems only provide limited options beyond 
the standard [23]. 

To augment the expressive power of access control languages, it is 
possible for a SA to use application programs written in some imperative 
language (e.g., C). However, the implementation of an acc*ess policy in a 
low-level, procedural language complicates the maintenance of an access 
policy and makes it difficult for SAs to reason about the consequences 
and effects of a policy specification. 

Tlie need for multipolicy specification using high-level specification 
languages with well-defined formal semantics has recently been recog- 
nised and a number of candidate proposals have been described in the 
literature [1, 7, 6. 15]. However, these proposals are theoretical in nature 
and performance measures for implementations of these models are usu- 
ally missing (albeit [6] is an exception). The contribution of this paper is 
to describe some practical implementations of logic-based specifications 
of access requirements to protect SQL databases that are ac*cessed over 
the internet. Another of our contributions is to show how practical im- 
plementadons of our approach preserves the well-defined semantics upon 
which the specification of access control policies are based. Evidence for 
the practicability of our approach is provided in the form of a number of 
performance measures that we discuss in Section 5. A Java program is 
used to implement a system that integrates our access control subsystem 
with client applications and an SQL database. We ch(x>se to use Java 
because of its practical importance. 

Recent work on protecting SQL databases has included [4], and [5]. In 
each of these proposals, SQL is used to implement access control policies 
for protecting the information in SQL databases, but without using any 
language-specific constructs for access policy formulation. The decision 
to use SQL to seamlessly protect SQL databases is a natural one and 
satisfies the attraction of requiring that a single language be used for 
implementing access control policies for protecting databases. However, 
SQL is a relatively low-level language (relative to logic languages), and 
SQL is not well -suited for proving properties of a policy specification [20]. 
As such, choosing SQL to formulate access policies for protecting SQL 
databases is not ideal. Moreover, in [4], the availability of an RDBMS 
that supports sophisticated request modification facilities [11] is assumed. 
Unfortunately, not all RDBMSs support the features that are required 
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for the suggested approach, and the formal semantics, upon which the 
proposal is based, mixes operational and declarative features. In [5]. 
the use of PL/SQL for implementing an access policy for protecting Or- 
acle databases is described. The approach applies only to Oracle SQL 
databases. Moreover, the proposal involves transforming a formal policy 
specification from [2] into an equivalent PL/SQL fonn. However, no for- 
mal translation procedure is described. What is more, the implemented 
code is low-level and hence suffers from the same shortcomings exhibited 
jf applications programs are used to implement access control policies 
(e.g.. reasoning about the formal properties of a policy implementation 
js complicated). 

The rest of the paper is organized thus. In Secdon 2. some basic no- 
tions in access control, RBAC, TRBAC and logic programming are de- 
scribed. In Section 3. the representation of RBAC and temporal RBAC 
(TRBAC) policies, by using stratified logic programs [22], is discussed. 
These policies are based on the RBACp 2 A ntodel that is informally de- 
fined in [26] and formally defined in [3]. Henceforth, we refer to the logic 
programs that implement RBACh 2 a {TRBACh 2 a} policies as RBAC 
(TRBA(0 programs. In Section 4. we describe our implementation of 
RBAC/TRBAC programs for protecting SQL databases from unautho- 
rized access requests. In Section 5, we give some performance results for 
our approach. Finally, in Section 6. soine conclusions are drawn and 
suggestions for further work are made. 

2. Ba^iic Concepts 

The RBAC and TRBAC programs that we consider in the sequel are 
represented by using a finite set of normal clauses [21]. A normal clause 
takes the form: 



H*-LuLi (m>0). 

The head of the clause, H, is an atom and 4i, Zf2> • • • ) ^ conjunc- 

tion of literals that constitutes the body of the clause. The conjunction 
of literals Li, Zr 2 , . . . , Lm tnust be true (proven) in order for H to be true 
(proven). A literal is an atomic formula (a positive literal) or its nega- 
tion (a negative literal)’, negation in this context is negation as failure 
[10], and the negation of the atom A is denoted by not A. A clause 
with an empty body is an assertion or a fact. In the sequel, we will be 
principally concerned with stratified programs. 

An RBAC program S is defined on a domain of discourse that in- 
cludes: 
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1 A set of users, 

2 A set (? of objecis. 

3 A set ^ of access privileges. 

4 A set 7^ of roles. 

The access privileges of interest to us in this paper are defined by the 
set: 



[selectfineerifdeleie, update). 

The semantics of the access privileges in A are defined thus (where D 
is an arbitrary SQL database, AD is an updated state of D. and ^ is a 
tuple): 

■ If a user u (u € i^) has the privilege .select on a set 0 of tuples 
(0 C D) and D ^ $ then ii is permitted to know that ^ 6 0 is 
true in D, 

• If a user u {u € U) has the privilege insert on a set 0 of tuples 
(0 C D) then u is permitted to insert d € © into D to generate 

ad ”* Due. 

■ If a user ti (u € tf) has the privilege delete on a set 0 of tuples 
(0 C D) then u is permitted to delete ^60 from D to generate 

AD^D-e. 

■ If a user u (u £ U) has the privilege update on a set 0 of tuples 
(0 C D) then u is permitted to change 0 to A0 and to generate 
AD^(D-Q) U A0. 

The Uy Oy A and 7^ sets, comprise the (disjoint and finite) seLs of 
user, object, access privilege and role identifiers that form part of the 
universe of discourse for an RBAC program. In this framework we have 
the following definitions. 

DetlnUion 1 An authorization is a triple (u, a,o) that denotes that a 
user u (xL ^U) has the a access privilege (a € A) on the object o (b 6 
0 ). 

Definition 2 If a is an access privilege ando is an object then a permission 
is a pair (<j, o) that denotes that the a access privilege may be exercised 
on o. 

Definition 3 A permi.ssion-role assignment is a triple (o, O, f) that 
denotes that the permission (a, o) is assigned to the role V. 
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Definitiou 4 A user^role assignmeni is apair(xtyf) that denotes that 
the user u is assigned to the role r. 

For TRBAC programs, in addition to elements from the sets Uy O, 
A aJtd TZy we require a set T of time points. We view time as a linearly 
ordered, discrete set of time points that are isomorphic to the natural 
numbers. 

Definition 5 A temporal authorization is a 4-tuple (u»a,0, t) that de- 
notes that useru has the a access privilege on object o at time t. 

In this paper, we a.ssume that a (T)RBAC program defining a closed 
policy [8] is used to protect an SQL database. The implementation of 
various open policies or any number of hybrid (i,e., open/closed) policie.s 
for protecting D necessitate.s that only minor modifications be made to 
the approach that we describe (sec [6]), 

In the sequel, the constants that appear in clauses will be denoted 
by symbols that appear in the lower case; variables will be denoted by 
using upper case symbols. Moreover, we will use the constants t*, o, a> 
r and t to denote a distinct, arbitrary user, object, access privilege, role 
and time, respectively. In clauses, we use the variables U, O. A, R and 
T to respectively denote a set of users, objects, access privileges, roles 
and times. 

The result that follows is an immediate consequence of a (T)RBAC 
program being a set of stratified clauses. 

Proposition 1 An (T)RBAC program S has a unique 2-valued well- 
founded model that coincides with the perfect model of S [9], 

Corollary 1 (T)RBAC programs define a consistent and unambiguous 
set of authorizations. 

In our representation of (T)RBAC programs, functions arc only used 
to express structured terms and do not lesult in unbounded terms being 
generated during computation. Moreover, if a {T^RBAC program is ex- 
pressed by using built-in comparison or mathematical operators then we 
assume that a SA will express these definitions in a safe form [27] such 
that the arguments of a condition involving these operators arc bound 
to constants prior to the evaluation of the condition. 

3. Representing {T^RBAC Programs 

The RBAC programs that we describe in this section arc based on 
the specification of RBAC as a normal clause program from [1]. In [1]. a 
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user U is specified as being assigned to a role R by a SA defining a 2-place 
ura(U, R) predicate in an RBAC program. For example, «ra(6o6, rl) 
is used to record the assignment of the user Bob to the role rl. To 
record that the A access privilege on an object O is assigned to a role 
R. clause form definitions of a 3-place pra(A, O, R) predicate are used. 
For example, pra{insert, ^ expresses that the role rl is 

assigned the insert privilege on the binary relation p provided that the 
pairs (X, Y) inserted into p are such that X = fl. 

An RBAC role hierarchy is represented by a partial order (i?, >) that 
defines a seniority ordering > on a set of roles R. Role hierarchies are 
used to represent the idea that, unless constraints are imposed, “senior” 
roles inherit the permissions assigned to “junior” roles in an RBAC role 
hientrchy. Hence, if € Ry Tj € ii, and > Tj then r% inherits the 
permissions assigned to Vj. 

Following [1], an RBAC role hierarchy is expressed in an RBAC 
program by a set of clauses that define a 2 -place senior _io predicate 
as the reflexive -transitive closure of an irreflexive- intransitive 2- pi ace ds 
predicate that defines the set of pairs of roles such that r, is 

directly senior to role Tj in an RBAC role hierarchy (i.e., is senior to 
Vj and there is no nde ^ such that is senior to r* and r*. is senior 
to r<). 

In clause form logic. senior_to is defined in terms of ds thus (where 
is an anonymous variable): 

senior 

senior Jo(RiyR2) ^ d3lRl,R2). 

senior Jo{R\yR2) da ( ill, H3), pernor i?2). 

To represent that a user u is active in a role r at a time an 
active (u,r) fact is appended to a {T^RBAC program whenever t* re- 
quests to be active in f and this request is allowed. The set of active 
facts in a (T^RBAC program at an instance of time t is the set of roles 
that users have active at lime t. 

The set of authorization triples defined by an RBAC program are 
expressed by the following clause: 

permitted(Uy Ay 0) uro(t/, Rl), active(Uy iZl), 
s enior^to (ill , il2) , pra ( A , O, il2) . 

The permitted{U, A, O) clause expresses that a user V has the A ac- 
cess privilege on an object O if t/ is assigned to. and is active in. a role 
R\ that is senior to the role R2 in an RBAC role hierarchy associated 
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with the RBAC program, and R2 is assigned the A access privilege on 

O. 

Only minor modifications arc required to extend RBAC programs to 
TRBAC programs. For a TRBAC program S. the set of authorization 
triples defined by S may be expressed by the following clause: 

permitted(U^AyO^T) ^ Urne(T),ura(U, Ri,T)yactive{Uy 

senior Jo{Rl, R2)ypra{A,0, R2yT). 

The permifted(U.AO.T) clause expresses that a user U has the .4 
access privilege on an object 0 at time T (extracted from the system 
clock using rime(T)) if U is assigned to a role at T, U is active in 
^1, R\ is senior to the role R2 in an RBAC role hierarchy defined by 
the TRBAC program, and R2 is assigned the A access privilege on 0 
at T. 

4. The Practical Implementation of (T)RBAC 
Programs 

In this section, we describe the practical implementation of RBAC 
and TRBAC programs for protecting SQL databases. 

We have adopted a modular approach to developing the software that 
implements our proposal. There arc three principal components in our 
implementation: 

• The Main Program. 

■ The Security Module. 

■ The Database System. 

The three components above are u.sed with a client application. We 
refer to an implementation that is based on these components as a com- 
posiie sysiem. It follows that a composite system E is defined in terms 
of a 4-tuple E = (MySyDyC) where: denotc.s the main program; 

S denotes the security module; D denotes the database system; and C 
denotes a client application. The key features and issues relating to a 
composite system S arc briefly outlined below. 

The Main Program. The main program ^ is written in Java: 
Java is a suitable language for this type of application because of its 
comprehensive server programming support (using Java Servlets [18]) 
and its ability to communicate easily with a DBMS using JDBC [19]. 
In addition, it is easy to access applications written in a variety of other 
languages (through the Java Native Interface {JNI) [17] mechanism). 
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Java's support for distributed processing means that it will al«) be well- 
suited for future developments that we are considering for access control 
in a distributed DBMS environment. 

The M module acts as a server program that receives access requests 
from a client application C. The client application is written in HTML 
for display in a browser window. All user data will be entered via the 
browser, and all data will be returned to a browser; this is typically 
the case with e -commerce applicadons. The principal function of the 
module is to call the S and X) modules to respectively authorize an access 
request and to pr<x:ess the request with respect to an SQL database. In 
the case of a SELECT request involving a query Q oxi the output 
pnxluced by the Af module is the set 0 of tuples that satisfies Q from 
P U 5; © is the answer that is returned to C by Al. Alternatively, ifthe 
request for authorization is denied by 5, an error message indicating the 
denial of service Is returned to C by A'J and no further action is taken; 
no request is passed to P and no DBMS activity occurs. 

We have developed two alternative implementations of a session man- 
agement system. We call these meth<xis Ml and M2 where: 

« Ml involves authorizing every database transaction individually, 
so the duration of a user session is precisely one transaction. This 
does involve a certain processing overhead, but gives a high level 
of security where the RBAC policy includes either temporal or 
dynamic separation of duties [26] constraints. 

• M2 establishes a longer session that remains current until either 
the user terminates the session, or the session is terminated by 
the system (by, say. a timeout mechanism). The role allocation 
the user is given is recorded by an entry in a database table used 
purely for this purpose. The M2 method has the additional benefit 
of being easy to extend to include temporal constraints (i.e.. con- 
straints on acc*ess that are more sophisticated than a mere inactiv- 
ity or )ength-of-session based timeout mechanism) and a dynamic 
separation of roles constraint. The latter option is straightforward 
to implement as our S module can directly consult the database 
table in which current role allocations are stored. 

The Security Module. Within the 5 module, we use XSB [24] to 
implement the logic program that defines the access control applicable 
to an SQL database to be protected. XSB offers excellent performance 
that has been demonstrated to be far superior to that of traditional 
Prolog -based systems [25]. Calls to XSB from Af iire handled by the 
YAJXB [29] package. YAJXB makes use of Java's JNI mechanism to 
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invoke methods in the C interface library package supplied by XSB. It 
also handles all of the data type conversions that are needed when pass- 
ing data between C and Prolog-based applications. YAJXB effectively 
provides all the functionality of the C package within a Java environ- 
ment. 

Although we have used YAJXB in our implementation of composite 
systems, we note that a number of alternative options exist. Amongst 
the options that we considered for implementing composite systems were: 

■ Intcrprolog [14]. 

• One of the Java-based Prolog interpreters currently available (e.g,, 
JavaI_og [16]). 

■ a Sockets-based. direct communication approach [12]. 

Each of the above approaches has its own distinct drawbacks when 
compared with the approach that we adopted. Interprolog does work 
with XSB, so we could still take advantage of the latter's performance 
capabilities. However, Interprolog is primarily a Windows-based appli- 
cation. All of our development was done on a Sun Sparc/Solaris sys- 
tem; YAJXB, though primarily configured for Linux, compiles easily on 
Solaris. JavaLog was discounted because we felt that it did not offer 
sufficient perfonnance for the types of implementations and volumes of 
data involved in practical applications of our approach. Finally, using 
sockets would give us a less flexible application because it would involve 
considerably more application-specific coding. Overall, we felt that the 
straightforwardness of the YAJXB interface makes it preferable to the 
Intcrprolog approach so far as interfacing with XSB is concerned. More- 
over, XSB’s highly developed status and excellent performance make it 
more desirable in this context than a Java/Prolog hybrid. 

Once XSB has been successfully invoked by S, XSB loads a program 
that contains the Prolog expression of an RBAC program (see above). 
This is used to determine whether the access requests made via the client 
application C are permitted (by 5) or not 

The C library allows the full functionality of XSB to be used, A 
variety of methods for pas.sing Prolog- style goal clauses to XSB exists. 
However, we generally found that YAJXB's string method worked well. 
This method involves constructing a string tr in a Java String type vari- 
able, and using the xsbj:i0mTnand.3tring function (or similar) to pass 
a to XSB. This approach allows any string that could be entered as a 
command when using XSB interactively to be pa.ssed to XSB by S. YA- 
JXB creates an interface object. The precise method of doing this is a 
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c«dl like 

i = a>re.x$bj^maTul^iring{cornmand.toString{)); 

where the assignment, «us one would expect, handles the returned error 
code. More sophisticated methods would allow for the return of data too; 
though this is not necessary where authorization is merely confirmed or 
denied. 

The key technical results for query evaluation on SQL diitabases pro- 
tected by using P U 5 follow directly from the soundness and com- 
pleteness results for SLG -resolution applicable to stratified theories. As 
<S is a function -free stratified program and YAJXB only passes facts 
to XSB it follows that every authorized access request is pnwable by 
SLG-resolution and no unauthorized access is pnwable by (safe) SLG- 
resolution. These results extend to TRBAC programs. 

Database System. Although 'Dj in a composite system, may be any 
SQL datiibase, we have used Oracle in implementations of our system 
(because of its widespread use within industry). A composite system 
could easily be adapted to apply to a large number of existing Ora- 
cle applications. For the interface between A1 and we have used 
JDBC [19]. JDBC is now a well-established technology and has the ad- 
ditional advantage that JDBC drivers exist for numerous DBMS pack- 
ages. It follows that, with minimal modifications, a composite system 
could be used with any DBMS with which JDBC drivers may be used. 

5. Performance Measures 

In any system where data is accessed over the Internet, by far the 
biggest time oveihetid will be caused by communications costs. As our 
model does not introduce any additiontd traffic (i.e.. the data sent by. 
and returned to, a remote user is the same as it would be if our authoriza- 
tion model were not used), this component of performance cost remains 
unchanged, and we do not therefore consider any specific time delay val- 
ues, Similarly, the overheads icssociated with accessing the DBMS are 
unchanged, and we agmn do not consider any specific values. 

The performance cost that we have added to a transaction is the one 
of calling the subsystem (»S) that we use to authorize access requests. 
Although the costs of using are minimal when compared with com- 
munication costs, we have conducted various perfonnance tests on an 
RBAC program that we use to protect SQL databases from unautho- 
rized iiccess requests. Our RBAC program includes a definition of a 
53 nde RBAC role hierarchy that hits been represented by using a set 
of facts to represent all pairs of roles in the senior_io relation (a to- 
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tal of 312 senior _to fads). For our SQL tests, we have used the data 
from [5]. There is one user, one ura rule, 8 database objects (tables) 
containing a total of 432,261 tuples, and 720 pra rules. It is sufficient 
for test purposes to use one user to demonstrate a worst-case use of the 
access control information in an RE AC program. This worst case test 
involves assigning a user u to the unique top clement in the RBAC role 
hierarchy, such that u has complete access to all of the tables used in the 
test queries. The permissions are assigned to the unique bottom element 
in the RBAC role hierarchy. Hence, our testing involves the maximum 
amount of multiple upward inheritance of permissions. 

The experiments were performed using XSB Version 2.5 on a Sun 
Ultra 60 server (2 450MHz CPUs and 1GB RAM) running Solaris. Typ- 
ically. the time taken to evaluate an authorization request is less than a 
hundredth of a second. Furthermore, where a user’s request for data is 
not authorized, no database access takes place at all and no processing 
costs are incurred. A summary of our results for “fixed" costs is given 
in Tabic 1, By "fixed" we mean the fixed overheads of invoking XSB. 



Op£r&lion 


Time (secoDds) 


SurtXSB 


0.07 


XSB loads and compiles I 
RBAC orotfram ! 


1.285 


XSB loads pracompilad 
RBAC program 


0.01 



Table 1, Fixed Costs 

The figures in Table 1 arc averages: each operation was performed 
five times. On first load of the Prolog program (which in this case 
represents our RBAC policy), XSB compiles the code tmd stores the 
compiled version. Subsequently, if the program has not changed since 
the last compilation, XSB loads the compiled version, with a significant 
reduction in the load time. 

The performance times that we give have been obtained using XSB’s 
siaiistics package. XSB gives times for CPU usage in seconds, accurate 
to two decimal places. 

Table 2 shows the results we obtained for a number of tests of access 
requests (averaged over ten runs). We performed worst case tests (sec 
above) and, for comparison, best case tests (where there is no upward 
inheritance of permissions). For each, we tested with data that would 
give both possible outcomes for the requested database operation. 
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Csse 


Outcome 


Time (seconds) 


worst 


permittsd 


0.002 


worst . 


denied 


O.OOl 


best ! 


permitted , 


0.002 


1 


denied I 


00 



Table 2. Variable Costa 

Given the magnitude of these figures, it is possible that mettsuring 
imiccuracies render the smidl differences between them difficult to eval- 
uate. We confine ourselves to noting that the query execution time is 
minimal when compared with the time taken to start XSB and load the 
program. The total time required to authorize adaUibitse access request, 
if the RBAC program has not been updated since the Uist time it was 
compiled, is about a tenth of a second. This comptues favourably with 
the results we obtained in [5]. where a PL/SQL-based implementation 
of our RBAC model took 1.08 seconds. 

In contrast to user queries on "Vy it should be noted that a SA may 
evaluate administrative review queries with respect to an RBACh^a 
program S directly. For extunple, to generate the set of users assigned 
to the role rl, in the process of perfonning a user- role review [26], a 
SA simply needs to use SLG-resoIution to evaluate the goal clau.se ? - 
C^.rl) with respect to S. 

For completeness, we performed a number of such queries; the results 
iMe given in Table 3. We believe that the appiffently identical times 
taken for almost all of the queries shows that the computation lime was 
too small for XSB to accurately record. 



Number of 
ura kcts 


iiiWjM 


Time 

(seconds) 


300 


] 


0.01 


300 


5 


0.01 


300 


40 


0 01 


600 


6 


001 


600 


65 


0.04 



l^ble 3. Retrieval times for test database D. 

6. Conclusions and Further Work 

We have shown how the information in SQL databases may be pro- 
tected from unauthorized access requests by using RBAC and TRBAC 
programs. The high-level fonnulation of an acce.ss policy as a logic pro- 
gram makes it relatively ettsy for a SA to express an ticcess policy, to 
reiison about its effects tuid to maintain it. Moreover, it is possible to 
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use this specification of policy in an implement at ion of composite sys- 
tems. We have demonstrated that the a:cess policies that we use for 

protecting SQL databases may be efficiently implemented. 

In future work, we intend to investigate how constraint checking on 

S may be incorporated into the approach that we have described here. 
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AN ADMINISTRATIVE MODEL FOR ROLE 
GRAPHS 
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Abstract Fiv ihe role grsph model, we have always assumed that the adminis* 
traiion of the role graph and group graph is carried out by a single 
(eeniralized) adminisiraior. This is noi realistic in practise. In this 
paper, we present a deceniralized administrative model for the role and 
group graphs. The model uses administrative domains, and administra' 
five roles which are part of (he role graph. A discussion of why domains 
cannot overlap is given, as well as a discussion of how users and privileges 
might be in more than one domain. Details of administrative privileges 
are given. We also present a detailed discussion comparing the new 
model to other administrative models for role-based access control. 

Keywords: role-based accc&s control, administration of acce&s control 

1. Introduction 

The role graph model ha5 been described in previous papers [6, 7], 
and is one version of role-based access control (RBAC). The model is 
described on three planes: the user plane on which users and groups 
can be modeled [9], the privileges plane on which implications among 
privileges can be modeled [3], and the role plane on which the role graph 
is built. The role graph represents role-role relationships by an acyclic, 
directed graph called Ihc role graph. A tool has been developed which 
allows users to interact with algorithms for a role graph and a group 
graph, and to assign users/groups to roles [10). 

Our previous papers have always assumed centralized administration 
of ihc role graph. This is not realistic in most applications of role-based 
access control. The motivation for using RBAC is that it helps with 
management of access control in an enterprise with many (i.e. thousands 
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of) users, roles and privileges. Such an environ inent is not manageable 
by one person. The purpose of this paper is to introduce decentralized 
administration for the role graph model, 

Cramplon and Loizou [1] imd Sandhu et al. [12, 13, 8] have presented 
administrative models forRBAC. ARBAC97. presented in [13], discusses 
users, roles and privileges, how they interact, and how they can be man- 
aged. ARBAC02, in [8], modifies the user and permission aspects of 
their previous administrative mtxlel. Cramplon and Loizou develop a 
concept called an administrative scope, which changes dynamically as 
the role hierarchy changes. Recently, others have also introduced admin- 
istrative aspects to RBAC models [4, 2, 15], We will give a more detailed 
discussion of these other models after introducing our own model. 

The paper is organized as follows: Section 2 reviews the basic con- 
cepts of the role graph model. Section 3 introduces the administrative 
model. Section 4 gives descriptions of administrative operations on reg- 
ular roles. Section 5 discusses operations on administrative domains and 
other administrative privileges, and includes a simple example showing 
how we get started. Section 6 contains a detailed comparison with other 
models. Conclusions are found in Section 7, 

2. The Role Graph Model 

In the role graph model [7], roles consist of a role name and a set 
of privileges, each of which is an (object, operation) pair. Roles are 
arranged in a role graph, with two distinguished roles: MaxRole and 
MinRole. MaxRole represents all the privileges in the role graph and 
need not be a.ssigned to any user or group, MinRole represents the lea.st 
privileges assigned to anyone in the system. We distinguish between 
direct privileges which are those directly assigned to a role, and effective 
privileges which consist of the direct privileges and those inherited from 
junior roles. The effective privilege set represents all privileges available 
to any user assigned to a role. Role T| is -junior to role rj if effeclive(ri) 
C effective{rj')- Role graphs have the following properties: 

- there is a single MaxRole. 

• there is a single MinRole. 

-the graphs are acyclic. 

- there is a path from MinRole to every role fj, 

• there is a path from every role to MaxRole, 

-for any two roles r, and rjy if €ffective(r,) C effective(r^), then there 
must be a path from fi to 

- by convention we draw the graphs with MaxRole at the top, MinRole 
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Figure 1. The Three* Plane Model 



al I he bottom, and junior roles lower on the page than their seniors. 
• we remove transitive edges from the display to make the graph less 
cluttered. 

The Group Graph model allows one to create sets of users, say to rep- 
resent committees or people assigned to a project, who may not have the 
same job title. To simplify the model, each individual user is regarded as 
a group of cardinality 1, The edges in the group graph arc determined 
by the subset relationship between two groups. By convention we draw 
the group graph with the Base group which contains all users at the 
bottom, and the groups representing individual user groups at the top. 

Conceptually, we view the model on three planes, as shown in Fig- 
ure 1. The structure of the group graph is developed on the left plane, 
the role graph is developed in the middle plane, and the privileges are 
represented in the right hand plane. Privileges are assigned to roles by 
operations on the role graph. We assume that if there are implications 
among privileges, all implied privileges arc included when a privilege is 
assigned to a role [3]. Users are assigned to roles by considering the 
interaction between the group graph and the role graph. Other oper- 
ations are available on role graphs to insert/delete roles, insert/delete 
edges and add/removc privileges from a role. Any of these role graph 
operations may alter the “shape" of the role graph when the role graph 
properties above are restored. As well, all of the operations abort and 
leave the role graph unchanged if a cycle would be created. 
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3. The Administrative Model 

The operations already available in the role graph model were mo- 
tivated by considering whal might be useful lo an administrator when 
trying to design the access control for a complex system. The structure 
of the administrative model presented here has been motivated by con- 
sidering a large corporate environment and the hierarchical management 
style that is likely to exist in such an environment. We would like the 
administration to be captured by administrative roles, which are a (spe- 
cial) part of the role graph. Special privileges will be developed to allow 
the administrative roles to carry out their administrative operations. 
The administrative model needs to be aware of the algorithms already 
available for manipulating role graphs, and possibly put constraints on 
the extent to which a given security administrator may make changes to 
the role graph. At the same time, the ixde graph properties must also 
be maintained whenever an administrative role alters the role graph. 

People in the business world usually draw a hierarchical organization 
structure called an organization chart or reports-to graph, which can 
alst) be called a supervision hierarchy [5]. The root node of this tree is 
the president or CEO; the lowest nodes are positions in departments or 
branches. This hierarchical structure is not the same as an RBAC n>le 
inheritance structure or role graph, because the higher level positions 
may have fewer privileges than the lower level positions. For example, 
the president of the company may only have privileges to carry out some 
very high level operations, and may not be permitted to look at idl the 
details of all the data under control of the RBAC system. 

In a typical company, access control is administered in a decentralized 
way by a group of administrators, security officers and other employees 
[11]. At the top, there is a CEO or CFO in charge of all security issues 
of the company. Under the CEO or CFO is an SSO (System Security 
Officer) whose responsibility is the creation and enforcement of the com- 
pany security policy. Depending on the complexity of the company, there 
might be department security officers (DSOs) or branch security officers 
(BSOs). They represent the local security administrators for possibly 
decentralized piuls of the company. Our administrative model must be 
able to describe such a decentralized management of access control. 

Our administrative model is built on the idea of an administrative 
domain. Administrative domains (or admin domains) have some rela- 
tionship to Crampton and Loizou's administrative scope and Sandhu's 
role range, but they have some important differences. The basis of our 
model is still the role graph, and the administrative roles will also be 
part of the role graph. The main idea is to divide the role graph into 
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Figure 2. Role Graph with Administrative Domains 



administrative domains in which operations can be carried out to alter 
the role graph, or users and privileges can be assigned to roles. We also 
need a way to relate administrators to the portion of the role graph that 
they are going to administrate. 

An Adminisrrafive Domain is a set of roles which contains a top -most 
role d called the domain identifier oi domain ID, and all roles in the role 
graph $ such that 5is-junior d, except for MinRole. In the role graph in 
Figure 2, several administrative domains are shown. As well, there arc 
administrative roles: SSO, Marketing Admin, Distribution Admin and 
Accounting Admin. Edges showing the relationship between administra- 
tive roles and administrative domains arc also shown in the Figure. This 
is a many-to-many relationship; for example the SSO administrates sev- 
eral domains in the example. The Distribution domain in the example is 
administrated by several administrative roles: Distribution Admin, and 
indirectly by Marketing Admin and SSO, 

The model also includes a single highest admin domain called the de- 
fault domain, which includes MaxRolc and MinRole. The administrative 
role assigned to administrate this domain should be the highest admin- 
istrative role in the company. This is the only administrator who can 
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make changes to MinRole. In previous presentations of the Role Graph 
Model, this highest administrative role was assumed but not shown, and 
this was the only admin domain present. Thus this administrative model 
is consistent with the original Role Graph Model. 

Consider the intersection / of two administrative domains. / = Z)j O 
Dj. If / is non-empty, then if / = D] or / » Dj. we say the domains are 
nested. If / is non-empty and not equal to or have an 

overlap. We do not allow administrative domains to overlap. The reason 
for this is the following. Suppose, looking at Figure 2, there is a role X 
which comes between MinRole and West Agent, and between MinRole 
and Clerk, By the definition of administrative domains, this n)le would 
be in the accounting, marketing and distribution domains. The adminis- 
trators of any of these domains could add or delete privileges to/from X, 
Thus these administrators could make changes to the role graph which 
would affect domains of which they are not the administrator. Thus, 
overlapping domains are not allowed. If there is some basic set of privi- 
leges which all domains need, they can be added to MinRole. The ca.se 
where only some domains need a common privilege is discussed below. 

Just as we do not want roles that exist in more than one domain, 
we also do not want edges that go from one domain to another. This 
can arise if privileges are allowed to be in more than one domain, which 
we would like to allow. There is always some data which may need 
to be shared between domains. For example, if each admin domain 
represents a branch of a large bank, the information about the bank's 
savings account customers should be available in every branch. Having 
such shared data means that there Ls probably some basic privilege like 
(customer data, read) which represents the sharing of the data. Creating 
a role with only this one privilege in domain D\y would cause an edge 
to any role in domain Dj which contains this same privilege. Having 
an edge from a role r\ in domain Di to a role in domain means 
that if another privilege is added to role ri» the role graph structure and 
algorithms will cause this privilege to be inherited by rg, which again 
means that the administrator of D\ is making changes that affect D 2 - 

There are several ways to deal with these shared privileges. One way 
is to put them all in MinRole. This may not always be feasible since 
they would also be inherited by every other domain. A second way, 
currently being implemented in a prototype [14], is to extend the model 
for privileges so that each privilege also has a domain ID. Privileges must 
have the same domain ID as the domain of any role they become part 
of. We can still equate the privileges by looking at the object name and 
ac^cess mode. 
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The third way to deal with shared privileges is to not have a domain ID 
attached to each privilege, but to cheek after each operation on the role 
graph if any edges have been created which cross domain boundaries, 
and if this is so, abort the operation (just as the current role graph 
algorithms abort any operation if a cycle would be created). If the 
security administrators arc careful to always put these shared privileges 
into roles with some privilege unique to the domain, then edges between 
domains should never result. 

Administrative domains also include users and groups from the group 
graph (not shown in Figure 2). We want it to be possible for a user to 
work in different domains (an employee might work at different branches 
of a bank on different days of the week), so that overlapping of the users 
in different domains is allowed. In the current prototype, each user has 
one or more domain IDs associated with it. 

4. Administrative Operations on Reguiar Roles 

Administrative roles, like other roles, have privileges. Since they arc 
just roles, these privileges could be anything. However, in keeping with 
the desire to keep the model intuitive to people running real companies, 
these privileges should be restricted to being administrative privileges. 
Algorithms for these operations have been presented and implemented 
for a role graph with centralized administration [7. 10]. They have to 
be modified in order to enforce the concept of administrative domains. 
We have to add constraints to the role graph operations so that the 
operations permitted do not alter parts of the role graph outside of an 
administrative role's administrative domain. Note that modifying the 
group memberships or group-role assignments docs not alter the role 
graph, but modifying privilege-role assignments can alter the role graph 
quite significantly. 

Here is a list of the operations needed and how they must be modified 
to maintain the desired properties of administrative domains. 

Add a privilege to a role: If an arbitrary privilege is added to a 
role, it will, by the inheritance caused by the is-junior relationships, be 
inherited all the way up to MaxRoIe. This is an example of where a 
local operation can affect parts of the graph outside of an administra- 
tive domain. We solve this problem by having an administrator of an 
enclosing domain (there is always one such domain, the default domain) 
add/remove privileges from the domain identifier, i.e. the top role in 
e^h domain, as direct privileges if necessary. Then the domain admin- 
istrator is constrained to choosing from the domain ID's privileges when 
adding a privilege to a lower role in the domain. Such a privilege ad- 
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dition does not alter the effective privileges of the domain ID, and thus 
docs not affect roles outside of the administrative domain. By adding a 
privilege to a role like West Agent (a privilege already available in Dis- 
tribution Mgr) in Figure 2, it becomes a direct privilege of West Agent, 
and an effective privilege of role Cdn Agent, The domain administrator 
is prevented from adding privileges to the domain ID (since this must 
be done by a more senior administrator). 

If the third technique for handling overlapping privileges is being used, 
then this operation, and all the other operations in this list, must be 
rejected if edges between domains result. 

Delete a privilege from a role: By the same arguments as just 
given, privileges may be deleted from an arbitrary role in a domain, 
but they will remain in the direct privilege set of the domain ID, Only 
an administrator of an enclosing domain may delete privileges from the 
domain ID, 

Add a role: There are two role addition algorithms given in [7]. The 
first one gives a role name, set of direct privileges, set of proposed im- 
mediate Juniors, and proposed immediate senior roles. The constraints 
that need to be imposed now are that the privileges must all be in the 
effective privilege set of the domain ID. and the proposed juniors and 
seniors must all be roles in the domain or MinRoIe. 

The second role addition algorithm gives the new role name, and 
proposed effective privileges. The role graph algorithm figures out its 
juniors and seniors. The constraint needed now is that the proposed 
effective privileges must all be in the effective privilege set of the domain 
ID, In the absence of privileges shared among domains, any juniors or 
seniors that the algorithm detects will all be within the specified domain. 
Delete a role: The current algorithm gives the user the choice of keep- 
ing the privileges in the deleted role’s seniors, or removing the privileges 
from the graph. In the administrative version, even if the privileges are 
removed from seniors, they must remain in the domain ID, 

Insert an edge: Inserting edges can make privileges be inherited by 
roles where they did not previously exist. To avoid making changes 
outside of the administrative domain, inserted edges must involve two 
roles from the administrative domain being altered. This can include 
the domain ID, 

Delete an edge: For similar reasons, deleted edges must have both 
roles from the administrative domain being altered. 

Assign a user ur group to a role: Both the role and the user or 
group must be in the same domain. 

Remove a user or group from a role: Both the role and the user or 
group must be in the same domain. 
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These operations together with a domain ID become privileges that 
can be assigned to the appropriate administrative roles, 

5. Operations on Administrative Domains 

In addition to the above privileges which can be assigned to adminis- 
trative roles, we need operations to create, destroy etc. whole domains. 
Important to these operations is a test of whether or not two domains 
overlap. We now discuss the details of these operations. 

Create a new domain given r, its domain ID: This operation may 
be executed by an administrative role of an administrative domain D 
which contains r such that r is not the domain ID of D. To create the 
domain, we need to perform a depth-first traversal to all juniors of r, 
except for MinRolc, and then check that the resulting domain does not 
overlap any existing domain. 

Delete a domain given r, its domain ID: This operation may be 
executed by an administrative role of an administrative domain which 
contains r such thatr is not the domain ID. All record of this domain 
must be removed, including any administrative privileges on it held by 
administrative roles. 

Assign an administrative role to an administrative domain: 
This operation deals with how the “Administrates" edges appear in the 
graph. Administrative roles can form an (administrative) domain by 
themselves, or as in the figure, can be the domain ID of another admin- 
istrative domain (by the definition of administrative domain. Marketing 
Admin and Distribution Admin in Figure 2 form an administrative do- 
main). In order to a.ssign. for example, the Distribution Admin adminis- 
trative role to the administrative domain whose ID is Distribution Mgr, 
the role responsible must be in an administrative position with respect to 
both the admin role and the domain. So, in this example, this could be 
performed by Marketing Admin or SSO. In general, then, this operation 
can be performed by an administrative role which administrates both 
the domain and the admin role in the operation. The topmost admin 
role (SSO in the exajnplc) has to be able to assign itself as administrator 
of junior admin roles. This is also consistent since SSO administrates 
the default domain, which includes itself. 

Assign Hn administrative privilege to an administrative role: 
This operation also can be performed by an admin role which adminis- 
trates both the domain and the admin role involved. It may be that not 
all the possible administrative privileges listed in the previous section 
should be assigned to every administrative role. Thus, for example, we 
could build admin roles which can only assign users/groups to roles but 
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cannol aller the role graph (lo represent the Human Resources Depart- 
ment, for example). 

Remove an administrative privileg;e from an administrative 
role: Constraints for this operation are as above. Every admin domiiin 
has the defaull admin domain’s administrator as an administrator. 

5.1. Other Administrative Privileges 

In addition lo the operations above on domains, there are some other 
admin privileges required. Initially, the system starts with the graph 
in Figure 3a. The initial admin role, SSO, needs the ability to create 
other admin roles, which it has by virtue of being the administrator of 
the default domain. In general, admin roles can also have the <d)ility to 
create other admin roles as their own children. This privilege would not 
be granted to all admin roles. All of the admin privileges are granted 
at the discretion of an admin role, so the SSO could create a Human 
Resources (HR) admin role, which could create users, and assign them 
to domains, whereupon the administrators of those domains can assign 
them to roles in the domains. The HR admin role could create other 
admin roles as its children, and give them the privilege lo create users, or 
other admin roles which are their children. Some of these administrative 
privileges are, then: 

Create a Child Administrative Role: An admin role with this priv- 
ilege c:m create sub- admin roles as its own children. The piu'enl role has 
administrative rights over the newly created child role. 

Assign the Create Child Privilege to an Administrative Role: 
This is lUso covered by the assign an admin privilege to an admin role 
operation above. 

Create a User with Domain ID: The admin role must be an admin- 
istrator of the Domiun given. 

Create a Group in the <»roup (iraph with Domain ID: The 

admin role must be an administrator of the domain. All users in the 
group must be in the domain. 

Add a domain ID to a user: The user may have additional domain 
IDs assigned. The admin role performing this must have an admin rela- 
tionship with the user and the new domain. 

Remove a domain ID from a user: The admin role performing this 
must have an admin relationship with the user and the domain. 

5.2. Building up the Example 

The system would start with the graph in Figure 3a. The SSO can 
add regular roles and admin roles, giving the second graph in Figure 3b. 
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Figure S. Building the Role Graph 



From this graph, either Marketing Admin or SSO can create Disiri- 
billion Mgr with Ihe appropriate privileges, and the Distribution Admin 
admin role, SSO can aJso create the Accounling role and the Accounting 
Admin role. From this Ihe graph in Figure 2 can be created. 

6. Comparison with Other Models 

We will begin by comparing our model with that of Sandhu [13, 8). 
There are of course many similarilies belween these two RBAC models. 
Our role graph corresponds lo the role hierarchy in RBAC96 and all 
subsequent versions of their model, our groups correspond lo the groups 
in RRA97 which are roles with users but no permissions assigned, and 
our privileges correspond to abililics in RRA97. In fact, abilities model 
ihc implications among privileges [3]. in that they form a bundle of 
privileges which should be assigned together lo roles. Our algorithm in 
for following privilege implicalions gives the detail of how to put logelher 
their abilities [3). Our group graphs provide more detail about how Ihc 
groups arc related. Nowhere, in Ihe Sandhu papers, is there a discussion 
of anything equivalent to restoring the role graph properties. There is 
no explicit mention of adding a permission to a role, although deleting 
a permission is mentioned. Both adding and deleting permissions can 
cause the effective privileges of Iwo roles higher in the graph lo become 
identical, in which case a cycle in the graph would be created. No 
mcniion of how lo deal with this is made in the Sandhu papers. 

When it comes to the administrative model, URA97 [12. 13], in or- 
der to control user-role assignment, uses Ihe idea of prerequisite roles. 
Clearly some way of constraining which users can be a.ssigncd is needed. 
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but we feel it is not necessarily best modeled by being already in a role. 
This is replaced in ARBAC02 by the idea of a user pool, which is popu- 
lated by the Human Resources department. Our idea of requiring that 
the user be labeled by the appropriate domain ID is meant to model the 
real-world situation of the user reporting to some manager. It can also 
correspond to the formation of user groups in our group graph model. 
The domain ID labeling of users is very similar to ARBAC02's u.serpool. 

For permission-role assignments, PRA97 [12, 13] uses prerequisite 
roles, which are replaced by permission pools in ARB AC 02 [8). Our 
idea is to have the usable privileges be those defined as effective privi- 
leges in the domain ID role. We give very good motivation for this in 
discussing how it works together with the algorithms in the role graph 
model. The effective privileges of the domain ID can be regarded as a 
permission pool. 

In general, in ARBAC97 [12. 13]. admini.strative roles are given con- 
trol over a role range, which informally has a single top and a single 
bottom node. We sec no gwxl motivation for having a single bottom 
to a role range. In a business environment, managers are given control 
over segments of the company. These segments may have subsegments, 
but the senior manager can usually have control over the finest details, 
which might also be in the control of a junior manager. Thus, our do- 
mains, have a bottom which stops just above MinRole; we feel this more 
realistically models what happens in real companies. Our discussion of 
the administrative operations shows no problems with this “open bot- 
tom” model when taking into account the role graph algorithms and 
properties. 

Cramp ton and Loizou’s model has a notion of an administrative scope 
for administrative operations [1]. Again, informally, this scope has a 
single bottom. The scope also changes dynamically to conform to a 
mathematical definition. We feel that our administrative domains, which 
do not necessarily have a single bottom, describe more realistically what 
happens in real companies. Moreover, the extent of the administrative 
domain should be the choice of the designer of the administrative model, 
and not a mathematical accident. 

The Enterprise RBAC Model [4] uses the term scopes to refer to col- 
lections of objects and administrative permissions. Scopes are arranged 
in a DAG. Administrative permissions apply to a scope and all its sub- 
scopes, or can be restricted to the one scope node, or can be excluded for 
a scope. To some extent, this corresponds to not necessarily assigning 
all possible admin privileges to every admin role in our model. There is 
no discussion of the problems of overlapping scopes. 
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In [15]. Wcdde and Lischka describe a model for cooperative, dis- 
tributed administration of an RBAC system. Their model is built on 
the idea of authorization spheres, which in turn consist units composed 
of subjects and objects. Units are arranged in a hierarchy which is dif- 
ferent from the role hierarchy. Authorization spheres do not overlap, 
although no motivation is given for this. 

In the role control center model of Ferraiolo et al., [2], administration 
is defined with respect to views. Views in turn are defined in terms of 
all seniors of a set of principles. In our terminology, views could have 
a single bottom and open top. Views are allowed to overlap. This this 
model is quite different from ours, 

7. Conclusions 

We have introduced an administrative model for the role graph model, 
which consists of administrative domains and administrative roles. There 
are several innovations in this new model. 

The administrative model clarifies the relationships between admin- 
istrative roles and regular roles. The regular roles are contained in ad- 
ministrative domain that is managed by an administrative role. An 
administrative role can manage its child administrative roles. We also 
show the administrative relations between the admin roles. 

The administrative model described here supports decentralized ad- 
ministration. Our previous model assumed the administration is cen- 
tralized. but large enterprises require decentralized control over access 
to data. 

The model also fine tunes the role graph by adding new definitions, 
properties, rules and algorithms. In addition to the admin domain def- 
inition. we introduced the definition of administrative roles. Domains 
cannot overlap in the role plane but can overlap in the user/group plane 
and privilege plane. The problem of domain overlap is examined in de- 
tail; solutions for solving the problem caused by overlapping privileges 
are discussed. Required modifications of old algorithms are described. 
New algorithms that manage domain and administrative roles are also 
discussed. 

We also compared our new model with other models in the literature. 
Our definition of administrative domain uses a “single top. open bot- 
tom" approach. We believe this approach is successful because it closely 
matches business management models. Our administrative model was 
designed based on a detailed analysis of business management. It should 
be easily understood by administrators and managers in the business 
world. 
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Abstract Our rolc-based/mandaiory access control (RB AC/M AC) security model 
and enforcement framework for inter-operating legacy, COTS, GOTS, 
databases, servers, etc., limits: who {user/user role) can invoke which 
methods (based on value and MAC level) of artifact APIs at what times, 
and who (user) can delegate which responsibility (user role) at what 
times. In this chapter, we focus on assurance for the timeframe of access 
(of a user to a role, of a role to a method, etc.) and the attainment of 
the Simple Security Property (i.e., a subject cannot read information for 
which it is not cleared) and Simple Integrity Property (i.e., a subject is 
limited to writing information at its own level and lower), which together 
can be used to support aafery and UveneKH. 

Keywords: Security Assurance, Simple Security, Simple Integrity, Safety, Liveness. 

1. Introduction 

As agencies continue lo assemble software artifacts (i.e,, legacy. COTs, 
GOTS. databases, clients, servers, etc.), into interoperating applications, 
security assurance is critical [I, 6. 10, II]. In the area of mandatory ac- 
cess control (MAC), assurance-related properties arc: Simple Security 
Properly, a subject can read information at the same or lower clearance 
level |3); Si riel *• Properly, a subject can only write information at ex- 
actly the level for which it is cleared [12]; Liberal Properly, a subject 
with a low clearance level can write to an object with the same or higher 
clearance level [3. 12]; and Simple tniegriiy Properly, a subject can write 
information at its own level and lower [5]. In addition, assurance must 
focus on application behavior with respect to its defined and realized 
security policy, to attain safety (nothing bad will happen lo a subject or 
object during execution) [8] and live ness (all good things can happen lo 
a subject or object during execution) [2]. 
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In (his chapter, we explore assurance for our role-bascd/mandalory 
access control (RBAC/MAC) security model and enforcement frame- 
work for interacting software artifacts [9, 13, 14|. Our approach focuses 
on which methods of APIs can be invoked based on the security classi- 
fication level of a role, the security clearance level of the user, and the 
values (parameters), time, and classification level of the method. Assur- 
ance guarantees are provided to insure that: a user (with one lifetime) 
playing a role (with another lifetime) can invoke a method (yet another 
lifetime) at the current time; the method invocation docs not violate 
MAC domination {Simple Security for read-only and read- write meth- 
ods, and Simple Integrtiy for read-write methods); and, a degree of safety 
(nothing bads happens when a user invokes a method) and liveness (all 
good things happen when a user invokes a method) is attained. 

In the remainder of this chapter. Section 2 defines our RBAC/MAC 
security model. Section 3 focuses on the formal proofs of the security as- 
surance guarantees for the available timeframe of method invocation and 
satisfaction of Simple Security and Simple Integrity Properties, leading 
to the attainment of safety and livencss. Section 4 concludes the chapter. 

2. A RBAC/MAC Security Model 

This section reviews the security model |13, 14] with delegation [9], 
Def. 1: A lifetime. LT. is a time interval with start time (st) and end 
time (et), [st. et). et > st. and st/ct is of the form (mo., day. year, 
hr,, min., sec.). Concepts of LTs X and Y are: X>Y means Y.st > 
XM and Y.et < X.et; X <Y sY X; if ST - max{X.8t,Y.8t} 
and ET = min{X et,Y.et] , then y n X is 0 if < 5T or [ST. 
ET] if ET > ST\ and LT = [rt,coj is current time (ct) onward, 

Def. 2: MAC concepts arc: Sensitivity levels. SLEVEL = {U. C. S. T) 
with unclassified (U), confidential (C), secret (S), and top secret 
(T) forming a hierarchy: U < C < S < T; clearance (CLR). the 
SLEVEL given to users; and. classification (CLS). the SLEVEL 
given to roles, methods, etc. 

For assurance. LTs can guarantee that definition and access to privileges 
will always satisfy time limits. MAC will he used to guarantee the Simple 
Security and Integrity Properties (3. 5]. 

Defs. 3 to 6 are for a distributed application of resources, services, 
and methods, with LTs and CLSs. 

Def. 3: A distributed application, DAP PL, is composed of a set of 
software resources (e.g., a legacy. COTS, DB, etc.). R = {fiili = 
each composed of services, 5| = * L,n<}, each com- 
posed of methods. l . 
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Def. 4: Each meihod Mijk = for 

i * l..mj * \..n„k * of 5»y of has name M^^*”**) 

LT (default |ct, oo]), € SLEVEL (default U), and 

parameters. 

Def. 5: Each service Sij - for i s= I..m, j = 

of Ri has name LT 5,^^ = (mm{Af,^f **},77ki;r{A/i^p'}j 

VA; = and = min{M^^lk = l..«y }. 

Def. 6: Each resource Ri = for i = l,.77i, has 

name LT Vj = 

and ^ = L.ni}, 

For assurance, we guarantee the dependencies that exist among the LTs 
(resource LT spans its services' LTs; service LT spans its resources' LT). 
and the minimality of CLS (resource CLS is minimum of its services' 
CLS; service CLS is the minimum of its methods' CLS), For examples, 
we use the U.S. Global Command and Control System (GCCS), with 
Figure 1 containing Joint and Component services with (CLSs). 

Defs. 7 to 18 involve the privilege specification process for user roles 
against resources, services, and methods. 

Def. 7: A its^j-ro/e l/fi = represents a set 

of responsibilities, and has name LT UR^"^ (default [ct, 

oo|), and URP‘-^ GSLEVEl (default U). 

Def. 8i A user-role list, URL = (URi\i = l..r}, has the r roles (Def. 
7) for DAPPL. 

For assurance. URs have specific LTs. used to check the "when " of access 
(i.e., can a user invoke a method at current lime) and CLSs to check the 
"if" of access (Le,, does a UR's CLS dominate a method's CLS). For 
privileges. URs can be granted access to methods which have CLSs at 
or below the role's CLS (see Figure 2). 

Def. 9: A user. U = [[/''«’■'''. is an entity accessing a 

client, and has a unique LT (default [ct,oo|), and 

IfCLR ^ SLEVEL (default U). 

Def. 10: A user list. UL^ {l/Ji » l. u}, has the u users (Def. 9) for 
DAPPL. 

For assurance, users have specific LTs for checking the "when" of access 
(i.e., can a u.serplay a role at current time) and CLRsfor checking the 
"if of access (i.e.. does a user's CLR dominate a UR's CLS). Repre- 
sentative users for GCCS are shown in Figure 2. 

Def. 11: A signature constraint. SC, is a boolean expression on 
A/^J*^”«,for i = l..mj = L.n.A; = to limit values. 
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(S) Joint Sorvie* (S) 
(S> 
(S> 
C8) 
( 9 ) 
C9) 
<3) 
(T) 

(3) Coapont&t Sorrle* (S) 
CS) 
(3) 
( 8 ) 



Vottbtr (ToImo): 

VldooTolneoDfnre&ee (Token, IronOrg, teOrf): 
JointOpegAttoftaPlanunlc g (TokOB, CrlflokUB) : 
CrinlePleturo (Token, CrleleHun, Grldl, 6rid3)i 
TroasportatioBFloe (Token) : 
LogiBltcaPlaBBingTool (Token. CrlalBHw) ; 

Def eneoKoe a ageSysten < Token) : 

HATOKessageSyetMti (Token) ; 

ArayBettLeCndSye (Token. Crlele)lua>; 
ALrForceBftttleRaiiegeaeotTya (Token, Crlelnkun); 
TtnriQ«Goe04tOpoeSya (Token, Crielekofli)] 
HneyCoemendSyatea (Token, CzleUHuo) ; 



Figure J. (jCCS Joint and C«>mponeni Services and their Methods. 



Koloe: [COk.Cftl, (01dec03.01<)ee03) . T] CJ?lWCkl, (CldecOS, 01jun09j . 9j 
[JPUnCR2. C01jul02,0ieep03}, O {ArayLogCSl, ClOdee02,OlBarO3j , 8j 
[AnyLo^CRT, [01JnlD9,0Uu^8] , C] 

Users; Caneral DoBeatr [DoBest, [cb, infinity], T) 

Colonel Dodood; iDoCood, [01dec03,0l jun09] , Tjb 
Hnjer DoRigbt: n>oHisbt . (014ec03,01)aa0d] , S] 

Major CanDoAl^t; [CanDofti^t, {OtjaA03.0l(»b03i TJ 
URAs: [JPlanCni, CiieisPicturei let, lafinity] .true] 

[JPlanCIU. Ar&yBattleCad3ys, [lOdecCT.lBf eb03) , tmel 

[AroyLosCRl, CtlsUPlcture , [lMec03,16febQ3] , GrUKHABO Um Grid3<NC40j 
CArmytoBCRTi LogPleaningTool . ClOdnc03,l6febO3J, CrisisKuA-nU] 

Figure 2. Sample Users. User*Roles, and User-Role Authorizations, 



Def. 12: A time constraint, TC. is a LT (default [ct.oo]), and is 
utilized as follows: LTs of UR and method constrain the method 
assignment; LTs of UR. method, and user, constrain the method 
invocation; LTs of UR and user constrain the user authorization 
to the role; LTs conslrtun the time sptm of a delegation. 

Def. 13: A mandatory access control constraint. MACC, is the dom- 
ination of the SLEVEL of one entity over another, e.g.. U's CLR 
> UR'S CLS or UR’s CLS > M’sCLS. 

For assurance, we provide guarantees that a user playing a role can in- 
voke a method limited by parameter values (SC - Def. ll), method avail- 
ability (TC - Def. 12), and the Simple Security and Integrity Properties 
applied by a user against a role invoking a method (Def. 13). 

The next set of definitions is for authorizations of method(s) to user 
role(s) and of user role(s) to user(s). to bring together all of the concepts, 

Def. 14: A user-role authorization. VRA = [UR. M. TC, SC], means 
UR (Def. 7) authorized to invoke M (Def. 4) within time TC 
(Def. 12 • default (d,oo]), limited by values SC (Def, 11 • de- 
fault true). Figure 2 has URAs for JPlanCRl. ArmyLogCRl, and 
ArmyLogCRl. 

Def. ISa: A r x q UR authorization matrix. URAM, where g = 
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VRx ia authorized to invoke Mj 

othermat 



Def. 15b: A valid user- role auihorizaiion list, VURAL = {VURAi V 
i = u < r X 9 , has all valid URAs (Def. 15a), 

Def. 16: A user auihorizaiion, UA = IU,UR,TCJ. means U (Def, 9) 
is authorized lo play UR (Def. 7) for lime TC (Def. 12 • default 
[ct» co)) for when the role is available to U. 

Def. 17a: An r x u auihorizaiion mairix, UAM, is: 

1 ““““ 

Def. 17b: A valid user auihorizaiion list, VUAL ^ {VUAi\i ^ 
u; < r X has all valid UAs, VUAs (Def. 17a). 

Def. 18: A clieni, C, is an authorized user U. identified by clieni when 
C = |U. UR. IP-Address, Client-Creation-Time], 

For assurance, a valid URA iDefs. 14, 1 5a and J5h) can only be created 
if all required checks of a UK's capabiliiies against a M's characierisiics 
are satisfied (i.e., TC and MACC checks), and ihe VURA then sets the 
criteria (UR, M, TC. SC) under which the invocation can occur. A 
corresponding set of guarantees also holds for a VUA. 

The remaining set of definitions are for role delegation [9], 

Def. 19: A delegaiable UR 6 URL, DUR. is eligible for delegation. 
Def. 20: The delegaiable UR vector, DURV, V r URs € URL is: 

DURV(URi) = ( ;^ HP “ ^ nf/ff 

' \ 0 1/ft IS not a DUR 

Def. 21: An original u.ser, OU € UL, of a UR is authorized to 

the UR via the security policy (3 a VUA for the OU/UR. i.e., 

UAM(UR.OU) = 1). and not by a delegation. 

Def. 22: A delegated u.ser, DU € C/L> is a user U that can be delegated 

a UR by an OU/DU (there is not a VUA for the DU/UR. i.e.. 

UAM(UR,DV) f 1)), where DU is not an OU for the same UR. 

Def. 23: The r x « user delegaiion/authorizaiion matrix, UDAM, is: 

f 2 C/ft ifl a DU of t/ft 

UDAMiURuUj)^ I 1 C/j is an OU of C/ft 

( 0 URj is not authorized to DUt 



For assurance, there musf he guarantees on the capabiliiies of an OU 
with respect lo the a DU lo insure that LTsYTCs and CLS/CLR are 
con.sisient; ike delegation is defined and checked ai runtime. 

Def. 24: Delegation auihoriiy, DA, is given to OU for delegation of a 
DUR to another user. 
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Def. 25: Pass-on delegation auihority, PODA. is authority given to 
an OU/DU to pass on DA for a DUR to another OU/DU. 

Def. 26: The r x u delegation auihority matrix, DAM, is: 

r 2 i/j haa DA* and PODA for UHi 
DAM{URi, Uj) = ^ 1 t/j has only DA for URi 

\ 0 UI^ hd6 neither DA nor PODA for URi 
Initially DAM has all 0 entries. 

For assurance, there must he DA and PODA guarantees; DA allows 
an OU/DU to delegate, and PODA, allows an OU/DU to pass on that 
delegation authority to another DU. which is a dangerous privilege. 

3. Towards Assurance (ruarantees 

Security assurance is critical in our model to allow the consistency of 
URs, CLR/CLS levels, LTs, role delegations, user authorizations, etc., to 
be verified when the security policy is defined, changed, and executed. 
Towards that end: Section 3.1 examines assurance guarantees on the 
available time of access for a method invocation; Secdon 3.2 details the 
attainment of the Simple Security and Simple Integrity Properties for 
method invocations; leading to Secdon 3.3 which explores safety and 
live ness. Overall, we have been influenced by others [4. 5, 8, 12, 15], 

3.1. Time-Based Guarantees 

To begin, we introduce available time, AT, which represents the max- 
imum amount of time derived from various intersections of LTs and TCs 
of the authorizadons for URs, OU. DU. and users, as given in Section 2. 
For example. URA = [UP, M, TC, 5C] involves LTs (for UR and M) and 
a TC, which must overlap to be a VURA. Formally, let 
where each represents a LT or a TC, using intersection for LTs/TCs 
as given in Def, 1. Then, any time t is in the maximum available time. 
AT, or i e PlEf^V f f e To a.s.sLst in the proofs, we define: 

Def. la: Let Compare(X. KJ be a function that returns the overlap 
of LTs X and Y. Compare(X, Y) = {Y ifXt>Y]X ifY>X\^if 
V'nX*^; ynX otherwise). 

Using Def, la, we offer lemmas for the ATs for URAs (Def. 14). URs 
(Def. 7). UAs (Def. 16), DUs (Def. 22) and Users (Def. 9). 

Lemma 1: If t/ilyti = [t/fl.M.TC.JC] is a VURA. then = 

Proof: 
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1 By Dcfs. 14 and 15a. URAi = [VR,M,TCySC\ as a VURA 
means UHAM{UR. M) = 1. By Def. 7, UR = 

UR^'^, Set URAf = 

2 By Def. 4, M = Apply 

Def. la with URAf^ = Compare(VRAf'^.M^'^). 

3 By Def. 12, a TC is a LT. In URAi = \UR.M.TC,SC\, TC 
constrains when UR authorized to M. Apply Def. la with 
URA^'^ * Compare(URAf^,TC). 

4 If VRAf^ f\ct = 0, then URAf^ = 0 and proof completes. 

5 Otherwise. URAf^ = M^^nC//?^^nT6’since it is equivalent 
to URAf^ » VRAf''^ C\TC (by steps 2 and 3 of the proof 
and substituting for URAf^ on the r.h.s. with 

Note that if VRAf^ = 0, then there is no overlap. 



Lemma 2: If VR - \VR^^^.UR^'^.VRp^% then VR^'^ = n^a 
URA^"^, where each URA^"^ is a VURA where URAM(UR, Mj) = 
1 for some j = 1 . .^. 

Proof: 

1 Consider URAM as given in Def. 15a. If URAM(UR,Mj) = 
0 for some jy then UR not authorized to Mj, and there is no 
need to use this entry to calculate UR^^. 

2 Consider all j where URAM(URyMj) = 1 (VURA of UR 
to M). If 3 at least one j s.t. URAM(UR,Mj) = 1 

s= 0, then set = 0» and proof completes. 



3 

4 

5 

6 



Let URAM{URyMj] « I and URAM{URyMk) = 1 for 
some j, k. Apply Def. la with UR^'^ = C(mpare(URAf^, 
where ij/ik is the VURA for Mj/Mk- 



Repeat this step for each remaining entry URAM{URyMj) = 
1, apply Def. la with UR‘^^ = Compare{UR'*'^,URAf/). 



If UR^^C\ct = 0, then UR''^ = 0 and prtxif completes. 
Otherwise, UR^'^ = n^iURA^'^. 



Lemma 3: If UA = [U. UR.TC] is a VUA, then UA^'^ = 0 

UR^'^ n TC. 

Proof: 

1 By Defs. 16 and 17a. UA = [U. UR.TC] as a VUA means 
UAM{UR.U) = 1. By Def 9. U = 

Set 

2 ByLemma2, (he AT of UR for all of its URAs. Ap- 

ply Def la with UA^'^ ~Compare(UA'*^, UR'*^}. UA'*’^ 
represents the time that U can engage an authorized UR. 
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3 By Dcf. 12. a TC is a LT. For VA^[U, VR, TQ. apply Def. 

la with =C'ompare(l/i4^^,rC). 

4 If nd » 0, then ^ 0 and proof completes. 

5 Otherwise, C/^4T _ ijiT p p since it is equivalent 

to VA^'^ — VA^'^ n TC (by steps 2 and 3 of the proof and 
substituting for on the r.h.s. with P UR^'^). 

Lemma 4: If OU delegates one of its DUR. UR. to DU, then DVA = 
[DV, UR. TC] has = OUA‘^^ P 

Proof: 

1 Let OVA = [U.UR.TC] be a VUA for OU. By Lemma 3, 

is the AT for an OU to a UR. Set DUA^'^ * OUA'^'^. 

2 For OU to delegate UR to DU, UAM(UR.OU) = 1. When 
OU delegates UR to DU. then UAM(UR. DU) must be set 
to 1. and a DUA = IDU. UR. TC] is created. The UR and 
TC in the DUA are as given in the OUA (Step 1), and thus 
do not impact DUA^^ since they are already in QVA^^. 

3 By Def. 9, DU = Apply Def. la 

with DUA^'^ = Ccmpare{DUA^'^,DU^'^y 

4 If DU net »» 0, then DU A'*^ * 0 and proof completes. 

5 DUA^^ = OUA^^nDU'^^ since it is equivalent to DUA^"^ - 
DU A'^^ n DU^^ (by Step 3 of the proof and substituting for 
DUA^^ on the r.h.s, with OUA^^). 

Lemma 5: If (7 = then ^ n^iUAf'^, 

where each UAf^ represents one VUA where UAM{URj,U) = 1 
for some j » 1..?*. This proof similar to Lemma 2 and omitted, 

3.2. MAC (ruarantees 

Mandatory axess controls are governed by strict rules for subjects 
(users) to access stored information or objects, and include many differ- 
ent properties: Simple Security Properry [3], the Sirici *-Properry [12], 
the Liberal Property [3. 12]. and the Simple Iniegrtry Property [5]. In 
this section, we prove that our RBAC/MAC model (see Section 2) satis- 
fies both the Simple Security Property and the Simple Integrity Property 
as applied to methods, roles, and users. To do so. consider: 

Def. 4a: Each = {^tjk I ^ ^ bas read-only methods, 

M.f = (M,^ for some ikj and rend- write methods, — 
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Def. 28: Let Dominaie{X. Y) be a boolean function, with X and Y ei- 
ther CLR/CLS (Def. 2) with U < C < S <T. Dominate(X. Y) = 
lirue if X>Y; false if X < Yj, 

Given these definitions, we present a series of lemmas on URAs, URs. 

and UAs in regards to the Simple Security and Integrity Properties. 

Lemma 6.1: If URAi = \URM.TCySC\ is a VURA, then URA, 
satisfies the Simple Security Property for all Af ^ and . 
Proof by contradiction: 

1 By Defs. 14 and 15a. URAi « \UR.M.TC,SC\ as a VURA 
means URAMiUR.M) = 1. By Def. 7, UR = 

where UR^^^ is the role’s CLS. Bv Def. 4, 
M = where is the 

method’s CLS. UR is the subject and M is the object. 

2 If M € Mif or M it has a CLS, Suppose 

Dominate{UR^^^,M^^^) ^ J<Use. Set URAM{UR, Af) = 
0 (Defs. 14, 15a. and 15b). 

3 This contradicts Step 1 where URAM(UR.M) = 1. 

4 Then, Dominate{URP‘-^, = true {UR^^ > 

5 This is Simple Security (read-do wn/no- read- up) [3]. 

Lemma 6.2: If URA, = \URM,TC,$Cfi is a VURA, then URAi 
satisfies the Simple Integrity Property for all 
Proof: Exact Steps as Lemma 6.1 except for Steps 2 and 6 (below), 
2. If M € M.-J^.it has a CLS. Suppose D<minat€{URP^^, 

= f^se. 

6, This is Simple Integrity (write-down/no-write-up) [5]. 

L<Miima 6.3: Let UR = [UR^^^, UR^'^. UR ^^^\ and q « UaUiURA,. 
where each URAi is a VURA {URAM(UR,Mi) = 1 for some 
j = L.g). \f Dominate{U R^^^ , Mf^^) = true for all URAi e cx, 
then UR satisfies the Simple Security Property for all methods and 
Simple Integrity Property for 
Proof: 

1 For each M 6 and Af € Daminate{UR^^^y 

^CLS^ » true (by Lemma 6.2), and, UR satisfies the Simple 
Security Property for all methods. 

2 For each M 6 Dominate{URp^^yM^^) = true (by 

Lemma 6.2), and, UR satisfies Simple Integrity for all A/^^. 

3 Steps 1 and 2 means that UR satisfies Simple Security for all 
methods and Simple integrity for 
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Lemma 7: If VA = [U, UR, TC] is a VUA, then UA satisfies the 
Simple Security and Integrity Properties for U CLR vs. UR CLS. 
Proof by contradiction; 

1 By Lemma 6.3, UR satisfies Simple Security Property for all 

methods and the Simple Integrity Property for jVf Hence, 
Dominate{U Ry Mk) = true for all authorized to UR. 

2 By Defs. 16 and 17a. UA = [U.URJC] a.s a VUA means 
UAM(UR,U) = 1. By Def. 9, 1/ « 

with 

3 Suppose that D<nr%inaU(U^^^^UBP^^) — false. 

4 Then. UAM(UR,U) = 0 (Defs. 16. 1 7a, and 1 7b), which 
contradicts Step 2. 

5 Thus. Dominate(U^‘-^, = true 

6 Since UR satisfies both Simple Security and Integrity Prop- 
erties, UA also does. 

Lemma 8: If OU delegates UR in DUR to DU, then a delegated 
user authorization DVA = [DU. UR. TC\ satisfies both the Simple 
Security and Integrity Properties for delegated user (subject) vs. 
role (object). Proof similar to Lemma 7 and uses Lemma 4. 

3.3. Safety and Liveness Cruarantees 

In this section, we explore safety (nothing bad will happen during a 
method invocation or delegation) [8] and liveness (all good can happen 
during a method invocation or delegation) [2] for our framework. We 
begin with a review of security assurance rules. SARs [9], which are 
logical statements that must be satisfied in order for a privilege to be 
set (design-time) or an action to be performed (runtime). The first four 
SARs are non-delegation checks at design time (Rule I for when an officer 
attempts to assign a method to a UR and Rule II for when an officer 
attempts to authorize a UR to a User) and runtime (Rule III for when 
a user selects a UR to play for a session and Rule IV for when a user 
attempts to invoke a method, via a client application). 

Rule I: Let A € UR and M be a method, VRA = [A. M. TC. SC] is a 
VURA iff TC - A^^CiM^'^nTC f 0, TC.ei > cv. 

Set URAM{A. M) = 1. VURAL ^VURALvURA. 

Rule II: Let A 6 C/R and X € UL. UA = [X.A.TC] is a VUA iff 
XCLR > xc = n n rc 5 ^ 0, TCer > a: Set 
UAMiA.X) = I. VDAMiA.X) = I, VU AL^VU AL\JU A. 
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Rule III: Let A € UR and X € UL. A can be authorized lo X at 
runtime iff VAM{A,X) = 1 (Rule 11 is OK), and for the VUA = 
\X,A.TC] € VUAL, TC,et > cl 

Rule IV: Lei A € UR, X ^ UL, and M be a method. X with A 
can invoke M at runtime iff UAM{A,X) = 1 (Rule 11 is OK). 
UDAM(A.Af) = 1 (Rule I is OK), for VUA = \X,A,TC] e 
VUAL, TCei > ci, for VURA « \A,M,TC.SC\ € VURAL, 
TC.ei > cr. SCOrocie([iW'““™, SC) = true. 

Note that in support ofSCOracle, we assert the following: There exists 
a SC Oracle that does noifaii The number and type of parameters vary 
with each method and SC will accept any combination. SC checks if the 
Boolean is satisfied, which has a very ht^h expectation of success. 

Rules V and VI are for the assignment of DA and PODA to a user X. 
Rule VII is for design-time delegation of a UR by a user to another user. 
Rule Vlll is for setting DA or DA/PODA from one user (either OU or 
DU) to another DU (Rule Vll OK). Rule IX is for activating delegation. 

Rule V: Let X € UL and A € URL. X has DA for A {DAM{A, X) = 
I ) iff UDAAd(A, X) = l(an OU),DURV(A) = l(a DUR), and 
3aVUA = [X.A,TC]. 

Rule VI: Let X € UL and A € URL. X can have DA and PODA for A 
(DAM(X, A) = 2) iff UDAM{A,X) = l(an OU), DURV{A) = 
l(a DUR), and 3 a VUA = [X,A.TC\. 

Rule VII: Let X € UL and A ^ URL, s.t DAM(AX) > 1 
(Rules V or VI). X can delegate A to user Y limited by TC iff 
UDAM(A.Y) ^ (Y^^n4^^nra) #0. 

and TC.ei > ct Set UAM{A. Y) = \,UDAM{A,Y) = 2, and 
VUAL « VUAL U UA * [K, A, TC\. 

Rule VIII: Let X ^ UL be anOU/DU. A € URL, and Y Q UL 
be a DU of A. Y can have DA for A (DAM(A.Y) = 1 ) if X 
has at least DA for A (DAM(A,X) > !)• Y can have DA and 
PODA for A(DAM(A,Y)=2 if X has both DA and PODA for A 
(DAM(A.X)=2). Rule VIII limited to 2 levels in our framework. 
Rule IX: Let X 6 l/L be an OU or a DU. Then X can delegate role 
A to DU Y limited by TC iff (Rule V or VI) and Rule VII. 

Now, we present theorems for the safety and liveness of Rules I to IV 
(delegation omitted). We define: legal access as an access authorized by a 
security policy; liveness to mean that every legal axess is authorized [2]; 
and. safety to mean that no illegal access is authorized [8]. 

Theorem I: Rule I meets requirements for liveness and safety. 

Proof: 
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1 Let A be a user role and M a method being authorized. 

2 Initially, the URAM is set to aJl Os. This is perfect access 
control as there arc no UR authorizations to any methods. 
Mijif, in this system. This meets safety (no bad things ean 
happen), but not livencss, as no good things ean happen. 

3 Lemma 1 ensures that a URA is a VURA and URAf^ = 

DTC- If URA^^ 5 ^ 0 and URAf^nct ^ 0, ihcn 
M ean be assigned to UR. Otherwise M cannot be assigned 
to UR because it can never be available. 

4 Lemma 6.1 insures 

5 To change an entry from 0 to 1 in a URAM, there must be a 
URA (Def. 14). 

6 In order to build liveness, yet maintain safety, 0 entries in the 
URAM must be changed to 1 {VRAMiAM) = 1) for only 
those URs authorized to Ms (Defs. 15a and 15b). Validating 
changes to URAM allows for both safety and livencss; there 
is no access except for these specific authorizations and this 
is precisely Rule I 

Theorem II: Rule II meets requirements for livencss and safely. 

Proof: 

1 Let X be a user and A be the role being authorized. 

2 Initially, the UAM and UDAM arc set to all Os. This is perfect 
access control as there arc no users, U, authorized to any user 
roles, UR. in this system. This meets safety requirements, but 
not livencss. as no user can do anything, 

3 U and UR must be available for access and (Tct 

0. Lemma 3 insures the maximum AT for a U to a UR. The 
intersection with the current time assiues that available time 
has not passed, whieh is obviously a requirement for use. 

4 Lemma 7 insures 

5 To change an entry from 0 to 1 in UAM/UDAM. there must 
be a UA (Def. 16). 

6 In order to build livencss, yet maintain safely, 0 entries in the 
UAM/UDAM must be changed. Validating changes to UAM 
and UDAM allows for both safety and livencss, as there is 
no access allowed except for these specific authorizations and 
this is precisely Rule II, 



The safely/liveness of Theorems III/IV focuses on the runtime autho- 
rization of user to role, which is needed since the tranquility of CLR and 
CLS is not guaranteed, URs can change, and LTs and TCs can expire. 
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Theorem III: Rule III meets requirements for livcncss and safety. 
Proof: 

1 Let X be a user and A be the role being authorized. 

2 If U AM{A,X) ^ I, deny runtime authorization. QED, 

3 Revalidate Rule II: TC - n.4^^ flTC ^ 

0. TC.el > d. If X^^'* < then Rule II fails. If 

TC = X^'^ n A‘-'^ n re = 0, then Rule II fails. If either ca.se 
is true, deny runtime authorization. QED. 

4 Else. Rule II is revalidated at runtime, so by Theorem II, Rule 
II satisfies safety and liveness. Thus. Ruie III docs as well. 

Theorem IV: Rule IV meets requirements for liveness and safety. 
Proof: 

1 Let X be a user, A its role, and M the method being called. 

2 = false, deny 
runtime authorization. QED. 

3 If U AM {AjX) ^ 1, deny runtime authorization. QED, 

4 \f URAM{A,M) 1, deny runtime authorization. QED. 

5 = 0, (Lemma 3) deny runtime authorization. QED, 

6 If U'^C.ei < deny runtime authorization, QED. 

7 Otherwise, Rules 1 and 11 are revalidated enusring safety and 
liveness. Thus, Rule IV does as well. 

Theorems V to IX correspond arc structured in a similar fashion to prove 
safety and liveness for Rules V to IX 

4. Conclusions 

This chapter has examined security assurance guarantees for a RBAC 
and MAC security model and enforcement framework [9, 13. 14], Section 
2 reviewed our RB AC/M AC security model with delegation. Section 3 
examined security guarantees with respect to available time (when an 
invocation can occur), security levels (authorizations of methods to user 
roles, and user roles to users), and for the attainment of safety and live- 
ness (related to authorization, invocation, and delegation). The main 
contribution in this chapter is the series of lemmas and theorems that 
provide validation for the Simple Security and Simple Integrity Proper- 
ties, which then lead to the stronger properties of insuring safety (noth- 
ing bad happens) and livcncss (something good happens) as methods arc 
invoked by users playing roles. Please sec [16] for further information. 

Acknowledgement: Thanks to Prof, C. Reynolds, USMA. Dept, of 
EE&CS for his input on the various formalisms/notation in Section 3, 
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Abstract Security of XML insiance is a basic problem, especially in enierprise with large 

number of users and XML ot^ecLs as well as complex authorizalions adminis* 
(ration. In (his paper, arole*based access conirol (RBaC) model based on XML 
Schema is proposed RBAC ha.s been proven to be efficient to improve security 
admin isiradon with flexible authorization management. XML Schema is a speo 
ification (o define format and contents of XML instance. Access control based 
on a schema will be transported to all its instances. As a premised alternate 
of XML Document Type Definition (DTD), XML Schema supports complex 
constraints for XML components, such as elements, atlribute.s, datatype.^ and 
groups. Also. XML Schema provides a mechani.sm to build rich reuse relation- 
ships between .schemas and elements. Ibese will be applied in reusable permis- 
sions in our model, whichefficiently simplify the security administration. Based 
on these feature.s fine-grained access control can be achieved. At the .same time, 
our model also supports instances-level authorization naturally, which provides 
a uniform mechanism for XML security. A abstract implementation is presented 
In this paper for our proposed model. "Pure” XML technologies will be applied 
in (he implementation mechanism, which make the system lightweight and can 
be easily embedded into existing systems. 



1. Introduction 

Because of iis platform -in dependent characteristics, XML [9] has been in- 
creasingly used in many environments to integrate applications and commu- 
nicate between systems. XML instance is a structured format with meta-data 
for real data. Because of the ability to express complex reference relationship 
between data, a XML instance may be generated from various resources with 
varying security requirements. On the other side, a user can be allowed to ac- 
cess only particular parts of a XML instance. For example in an enterprise, 
a XML document can consist of information from applications among a tew 
departments and several databases. When an internal or external user uies to 
access this document, his/her access rights have to be monitored according to 
security policies in all these departments and databases. The final instance 
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which the user can read or modify is the result of enforcement with overall 
auihorizalions. 

In this paper, an access control m<xlel Is proposed to control all accesses 
to XML instances in such distributed and heterogeneous environment. In an 
enterprise or organization, there are large number of users and XML objects. 
Also, there are complex relationships among users, objects, and arbitrary au- 
thorizations between users and objects. Each user has identification and at- 
tributes, An object can be a XML document, message, dynamically generated 
XML instance, or any XML elements. Because of the complex data sources 
with different security policies, authorizations management will be burden- 
some. Role-based access control model [L 2] has proven to be efficient in se- 
curity administration with roles providing a layer of indirection between users 
and objects. The role-permission assignment is comparatively stable while 
user-role assignment can be more dynamic. At the same time, RBAC provides 
strong data type abstraction ability. All the components in the m<xlel can be 
customized and fit into particular applicadons very easily. 

XML Schema (11, 12} is a mechanism to define the content and relation- 
ship of elements in an XML instance. A well-validated XML document must 
follow the format specified by one or several schemas. In ourpropc'sed model, 
permissions a user can invoke are defined on schema or schema element level 
and will be transported to all XML instances specified by these schema or ele- 
ments. The permission on a schema cx>mponent will be transported to all XML 
instance data which is specified by this cx>mponent. At the same time, substan- 
tial permission reuse can be generated based on the rich relationships between 
elements, datatypes and attributes in a schema, or between schemas. We will 
use these relationships to build permission reuse hierarchy. Based on this, fine- 
grained. flexible, and easy-customized acc'ess control model can be achieved. 
With the unique features of XML Schema, extensible, modular and reusable 
security policies can be generated in distributed environment. 

The remainder of this paper is organized as follows: Section 2 presents the 
background of XML Schema and the main difference from DTD, Secdon 3 
describes and discusses the model in details. Section 4 briefly presents the 
high-level implementation of the acx;ess control model. Section 5 reviews the 
previous work on XML document secxirity. The difference between this work 
to others is presented, Sec'don 6 concludes the paper and outlines the future 
work to continue on this topic. 

2. XML and XML Schema 

XML instance has two ba.sic requirements: well-formed and validate-formed. 
Well-formalization requires XML d<x:ument to follow some syntax, such as, 
there is exacily one element that completely contains all other elements, el- 
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emencs may nesi but not overlap, etc. Validation requires XML instance to 
contain specified elements and attributes, following specified datatypes and re- 
lationships. Document Type Definition (DTD) and XML Schema are two main 
validation specification mechanisms. 

Document Type Definition(DTD) is the first and earliest language to de- 
fine the structure and content of XML documents. But it has many limita- 
tions which are critical in enterprise and distributed environments. A DTD 
file is not icselt a well-formed and valid XML document. The rules in DTD 
are not meta-data, but rather some special formats to show the order of ele- 
ments. The problem with this is that a special process is needed for an XML 
parser to parse the content m DTD, Another problem is that it is difficult to 
specify constraints on structure and content of XML instance with DTD. Actu- 
ally, DTD only specifies the appearance order of element and its subelements 
and attributes, but cannot define complex relationships and constraints, DTD 
cannot define datatypes, which make it difficult to be reusable, extensible, and 
modular. A defined DTD cannot be used by other DTDs, and rules in DTD 
cannot be reused and extended by other rules within or out of this DTD, All 
these limitations prevent DTD from being widely applied in distributed and 
scalable systems. XML Schema is an alternate in modem enterprise environ- 
ments with some new features. XML Schema is XML document itself, which 
XML parser can handle just like normal XML instance. Therefore, XPath 
and XQuery can be applied to specify fine-grained schemas objects. Com- 
plex user-defined datatypes can be created in XML Schema. Rich description 
and relations of schemas and components can be expressed. Hierarchy can be 
established based on these relationships. This makes schema reusable and ex- 
tensible. Namespace is supported in XML Schema to solve name conflictions. 
This helps modular deployment of security administration in our model. 

With these reasons, modem XML specifications are all ba.sed on schema. At 
the same time, the improvement of XML Schema results in flexible schema- 
ba.sed access control policy. With DTD’s limitations, permission based on 
DTD is not modular, extensible, and reusable. The access control policy on 
XML instance documents and DTD have to be implemented separately, since 
DTD is not XML well-formed and valid -formed. By using schema, we can 
define and enforce the permissions on schema objects and instance objects 
with uniform mechanism. Also, in disuibuted environment, the authorizations 
from various services and departments can be assembled easily with pure XML 
technologies, since policy based on schemas is extensile and reasable with 
schema's characteristics. 
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Role-based access conlwl is a policy- neutral model studied by many re- 
seajchers during the past decade. T^e flexibility and efficiency in security 
management make it an attracdve access control solution in many commercial 
systems. The main components of RBAC96 model includes users, roles, role- 
hierarchy, permissions, user-role assignments and permission-role assignment 
(1]. 

Figure 1 shows our proposed model extended from original RBAC96 model. 
The users, roles, role hierarchy, user-role assignment and sessions are the same 
as that of RBAC96 model. Instead of direct assignment of roles and final per- 
missions. in this model, there are schema-hased permissions {SP) and explicit 
role-permission assignments (EPA) between roles and schema objects. SP 
are defined by associating some atomic access types with schema components. 
EPA is the assignment between roles and SP. By the instance mapping (IM) 
function from schema objects (SO) to instance objects (10), SP and EPA 
imply the instarx:e-based permission (IP) and implicit role-permission assign- 
ments {I PA). Secure Schema Object Hierarchy (SSOH) is a partial <irder 
between schema objects defined by a security administrator, in which the per- 
missions defined on low level objects will be transported to high level objects. 
Some constraints are specified for the SP and EPA. 
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Figure I. Extended RBAC Mixlel 



Extended RBAC Model: 



a U (Users). R (Roles), P (Permissions). S (Sessions), AT (Access Types). 
10 (Instance Objects), SO (Schema Objects), SP (Schema-based Per- 
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missions). IP (Inscance-based Permisson). IM (Instance Mapping). SSOH 
(Secure Schema Object Hierarchy) 

■ S. VA and RH are same as RBA(T96 

• C AT X SO: Schema-based Permissions 

■ IP C AT X JO: Instance-based Permissions 

• IM : SO -» 2^^: Instance Mapping 
m P = IP U SP: Permissions 

■ SSOH C SO X S0\ Secure Schema Object Hierarchy 

■ EPA C K X SP\ Explicit Role-Permission Assignment 

■ IP A C Rx IP: Implicit Role*Permission Assignment 

IP A = {(r IP] \ 3(at : AT, so : 50, io : JO)Kr, {at, «o)) € 

EPA] A [ip s= (r, (at, io))j A [lo € JM(ao)j} 

■ PA = EPA U IP A: Permission-role Assignment 

■ schema _permixsions : R — * 2^^, a function mapping a role to a set 
of explicitly assigned schema-based permissions. 
sch^a.penni3Sions{r) * {ap : 5P | (r, sp) € EPA} 

m schema jyermissions ' : R —* 2^^, a function mapping a role to a set 
of explicitly assigned schema-based permissions with SSOH. 
6chema.peTmissions*{r) * {sp : $P \ 3(so : SO, so' ; 50, at : 
AT) ' [{ 30 ' < 30 ) A (ap = (at, so)) A (r, {at, so')) € EPA]} 

■ schema _}}ermissi<ms ” : R —* 2^^, a function mapping a role to a set 
of explicitly assigned schema-based permissions with SSOH and RH. 
8chema^rmi83i(ms**{r) = {sp : SP | (3r' : Roles) • [(r' < r) A 
\sp € ac^ma-permiasion*(r')]} 

• instance _permisstons : R — » 2^^, a function mapping a role to a set 
of implicitly assigned instance-based permissions. 
instance 4 fermi 88 iort 6 {r) {ip : IP\{r, *p) € I PA} 

■ instance _permissions‘ : R — » 2^^, a function mapping a role to a set 
of implicitly assigned instance-based permissions with SSOH. 
m«ancc-perTniaaiona*(f) = {ip : IP \ 3(ot : AT, so : 50, to : 
/0)[(r,(at,so))€ 

8 chema 4 >€rmi$ 8 im“{r)] A (ips= {r, (ot,io))I A (to € JA/(ao)[} 

• instance _permissions '' : R — » 2^^, a function mapping a role to a 

set of implicitly assigned instance-based permissions with SSOH and 
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RH. 

in$tance4)ermis$icn9'*{r) ^ {ip : IP \ 3(at : ATySO : SO^io : 
10) • l(r, {at, ^o)) € 6 chema4>ermi99ion^*(r)\ A (tp » (r, (aC,io))| A 
[io € /M(«o))} 

In the following subsections we will explain details of the main wmp<^nenLs 
in this extended RBAC model. 

3.1. Objects 

Definition 1 (Schema Ohjecfs (SO)) A schema object is a XML Schema or 
schema components), may he patterned hv anXPath orXQuery expression. 

Definitioii 2 (Instance OhJects(IO)) A instance object is a XML instance or 
instance components ). 

Definition 3 (Instance Mapping) Instance Mapping (IM) is a mapping be- 
tween SO and IO: 

IM : SO 2^^, and $90iy9<>2 € SO,io € 10 • {$ 0 i ^ 3 O 2 ) A {io € 
TM(90i) a io € IM(so 2 )) 

Since it is a well-formed XML d<x:ument, a XML Schema can be treated as 
a tree structure, with nodes us the schema elements, attributes and datatypes. 
XPath can be applied on schema to capture the tree paths with particului con- 
ditions. A path can be absolute starting from the root, or reladve from cur- 
rent pK^sition. For example. ‘T* is to return the r<x>t element of a XML docu- 
ment. while "customer Info/name" selects the child element of "name" in 
"customer Info". Another example, "customer Info[@gender = "Male"]" 
selects all customer Info nodes where the value of gender attributes is equal 
to '‘Male", XPath can select nodes which satisfy some conditions, such as, 
"customer Info/hilUng Addres.s[state = " VA"]" selects all the customer Info 
nodes with Virginia state of billing address. There some built-in functions and 
in XPath to strengthen the capability of expressiorts, which can satisfy most of 
fine-grained specifications, 

IM is a orxe-to-many mapping relationship from SO to 10. In our model, 
we use IM to implicitly specify the authorization In Instance level. Specifi- 
cally, the permissions defined on schema object will be transported to all its 
instance objects. 

3.2. Secure Schema Object Hierarchy 

Definition 4 (Secure Schema Object Hierarchy (SSOH)) SSOH is the partial 
order relation.ship between .schema objects: SSOH C SO X SO 

Mostly SSOH is based on reuse relationships between schema objects. The 
reuse relationships can be regarded as partial order with acyclic, transitive and 
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reflexive relations. Several types of reuse mechanisms have been specified in 
W3C XML Schema: 

1 Datatype library. A datatype library consists of basic schema datatypes 
as building blocks. Schema elements and attributes can be created with 
these basic datatypes by specifying their '‘type” name. 

2 Datatype dcrivadon. New datatype or element can be derived from ex- 
i sting datatypes defined in the same schema or other schemas. There are 
two types of derivations: restriction and extension. 

3 Schema clement reference. Without duplicated its definition, a new ele- 
ment can be created by referring to another element in the same schema 
or from other schemas. 

Some modularity mechanisms have been specified by W3C XML Schema to 
reuse datatypes and elements defined in a different schema, specifically in- 
cluding “include”, "redefine” and "import”. The first two only can be applied 
under the same namespace, while the third one can be used between different 
schemas. 

Note that it is the security administrator’s duty to decide which schema ob- 
jects will be put in the hierarchy. At the same time, other relationships can be 
used in SSOH definition by a security administrator, 

3.3. Access Types 

In this model, four basic access types have been considered to an XML 
object: Read. Create, Update and Delete. 

[ Read: "Read” XML information is the most frequent access to external 
users. A user activates some roles and try to read some instance informa- 
tion, The authorization enforeement point checks the permissions 
defined on the schema objects with these role. 

2 Create: “Create" access type is particularly for the document composer 
or source of message. The composition operation has to be verified by 
the composer’s permission on the targeted XML information before stor- 
ing or transporting. The final version of the created instance may be 
validated by a schema, 

3 Update: "Update” permission is to modify the content of a XML object. 
Also the final version of the modified instance may be validated by a 
schema. 

4 Delete: “Delete” is to remove a XML instance or elements in an in- 
stance. including the elements and contents. Besides the security cheek, 
XML validation check will be launched as well. 
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3.4. Pennissioiis 

Definition 5 (Schema-based Pemiissions (SP)) A schema-based permission 
(explicit permission) is association ofa schema object and its allowed access 
type: $P C AT X SO 

Delmilion 6 (Instance-based Permissions (IP)} An instance-based permission 
(impiicit permission) is asstfciation of an instance object and its allowed access 
type: IPCATx 10 

DeHnition 7 (Permission Reuse] In SSOH. 'id0\,$02 € SO^ai € AT, {soi < 
A € SP) ^ [at, $ 02 ) € SP 

Permission reuse greatly reduces the number and complexity of permissions 
needed to define. This will simplify the authorization management of the ac- 
cess control system. At the same time, modular and extensible security policy 
can be achieved by using existing permission based on building block objects, 
TTie permissions for new schema objects is extensible with capacity of adding 
new permissions besides the inherited permissions. 

3^. CoiLstraints 

Some constraints are introduced in our model to make it fine-grained and 
flexible. 

1. Recursive 

"Recursive ’’ constraint is used when permission based on a schema component 
will be automatically transported to all its sub-components, such as, a Read 
permission on an element will transported to all its sub-elements and attributes. 
Since schema objects are nested meta-data structure, recursive transportation 
can happen in several levels. We use r(n) to express n level recursiveness. 
r(0) means permission not transported, while r(cc) means always nested re- 
cursiveness, For example. (Read, /.r(co)) expresses the permission cti Read 
access to a schema, and to all components in this schema. 

2. Recursive Direction 

In some cases, permissions on schema component can be transported to its 
super-component. Sometimes this bottom-up recursive direction is useful. For 
example, if role CSR (Customer Service Representative) has "Read" permis- 
sion on CrediiCard element, the role will have "Read" permissions on all 
other elements or schemas who include this element, since credit card infor- 
mation is normally more sensitive than it's super elements. We use + and - 
to present top-down and bottom-up directions respectively, such as r* -j- (n), 
r - (n). 

Other constraints can be defined according to the real service and business 
logic by system designer and security administrator. 
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3.6. Explicit PerniLssion on XML lastance 

So far in our model we assumed ihat an XML instance is defined by a 
schema. The explicit permissions defined on schema objects implicitly spec- 
ify the permission to instance objects. In real world there are two cases that 
instance-level authorization is desired: one is that there are some "arbitrary'' 
XML documents without schema validation; another is that fora schema, the 
authorization lor an instance is different from other instances. For these cases, 
the permission should be defined based on the instance level. Since XML 
Schema itself is a well-formed XML document, the permission specification 
can be easily applied to instance objects without any change. Both schema and 
instance objects can be expressed in XPath orXQuery. The only thing with ex- 
tra consideration is to specify which level object is used in explicit permission. 
This is one of the benefits of the proposed schema based access control model. 
Generally the permission on instance level will overcome that in schema level. 

4. High •level Inipleinentation Mechanism 

XML provides a uniform mechanism to solve problems in heterogeneous 
environment. Figure 2 shows the server-pull [2] implementation architec- 
ture, All the messages transported among the services are identified in XML. 
XML requests and responses are XML messages, whose format will be de- 
fined in schemas. We will use some existing XML standard to transport the 
security information, such as SAML (Security Assertion Markup Language) 
(13J. With SAML. the messages for user authentication, user-role assign- 
ment request/response, permission-role assignment requesi/response will be 
in standard format. And the underlying mechanism of user authentication, 
role server, and policy server can be abstract. That means, the implementa- 
tion mechanism can be embedded to other systems very easily. This is an 
important advantage with” pure" XML implementation. Figure 3 shows an 
algorithm for the process of access control decisions. Tbe algorithm is de- 
scribed in a way for clear exposition rather than efficiency. Implementation 
details of the XML mechanism will be our future work. As shown in the al- 
gorithm, an access request includes a user information (u\ role activated by 
the user (r), access type (af). and the target XML document {target. xml) to 
be accessed. To make an access control decision, some other related informa- 
tion is needed, such as the schema(s) of tar get. xml {target. x:;d}, the possi- 
ble expected output schema {target' .xsd), as well as the security information: 
user-role assignment {UR.xml}. permission-role assignment {PR.xml}, role 
hierarchy {RH.xml). and Secure Schema Object Hierarchy {SSOH.xml). 
In some ca.ses. the output of an access control decision is required to satisfy 
some expected schema. The function im{targ€t* .xsd) is to check if output 
target' .xml can be validated by target' .xsd. Since the authorization process 
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Figure 2. High*level Implemenia* 
lion Architectuie 



can remove some nodes of the inpul object, ihe output may nol satisfy some 
particular schema, which is required by most applications. In this case, ihe 
access will be denied. 

Function rolt3{u) returns a set of roles assigned to a user, including direct 
assignment and inheritance with role hierarchy. Function parse(targel.xml) 
returns a set of data with tree structure, R^reach instance component i, func- 
tion ^m(i) returns its corresponding schema object. The key part of the algo- 
rithm is a recursive method recur aiv€jicc€ss{t, rootnode), which is a depth- 
first algorithm. For each subtree f, the method first checks the permission 
to the root node. If the access lo it has been permitted, all subtrees will be 
checked by ihe same mechanism. Otherwise, access lo the whole element and 
its sub-elements will be denied. 

Function.? _permissions{at.T,PR.xml. RH.xml, SSOH.xml) returns a 
set of schema mxles which is accessible lo r or a subrolc off in role hierarchy. 
PR.xml is defined for each schema. There ;ue different implementations of 
this permission-role assignment. Here, we just provide a simple and abstract 
structure as shown in Figure 4. The basic format is similar lo a schema doc- 
ument. In this example, each schema component is followed by one or more 
< permission > tags to specify thepennissions. A < permission > tag has 
two attributes: role and access. The value of < role > is a role name, and 
the value of access is a pre-defined access type. Since RBAC is a close model, 
any other role which is not specified in the < permission > of a schema 
component cannot access this object. Because of the large number of schema 
objects and roles, in the real implementadon. a visual tool will be developed lo 
do the permission-role assigrunent. 

UR.xml and RH.xml are more static in real implementation mechanism. 
UR. xml is very straightforward. The main a^mponent is a user information 
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XML-bMcd Algortthm; 

Input: Access request: {\i,r,(il,tiirgtt.xml) 

Schema of target; Uirget.xsd 
Schema of expected output: torpet'.xsd 
Security information; PR.xrrU. UR.xtni, RH.xmt, SSOH.zmi 
Output, target'.xml 
Method 

// Verify user-role assignment: 

1 ) \fr f rotes (u, V R xml, RH.xmi) 

2) ACCESS denied; 

3) eodif 

// Parse aod genetate msiance tree t rooted in rootTujde of torget.xml: 

4) t = paTse(target.xml) 

5) recur sive-ooeessit, rootnode) 

6) so = am{rootiiode) 

7) If JO € s.permissi(m5iat,r,PR.X7nl,ItH.xrnl,SSOTf-Tml) 

S) ACCESS Tooinode ispenmied; 

9) add{taTgei'.xml,rootnode); 

1 0) Jf (rootnode is not teaf) 

1 1) tdreacb sutpfree si ^ t rooted m subnode 

1 2) Recursive jKces3{st, subnode ) ; 

13) endfor 

14) cndif 

15) else 

16) ACCESS t is deoied; 

1 7) end recur 8ive.aceefla; 

// Validation check with torget'.xml accocding to target'. xsd if needed; 
i 8) If target' .xmi € im{target' .xsd) 

1 9) Output target '.xml ; 

20) else Access tar get. xnU denied; 

21) eodif 



Figure 3. Algorithm of XML Access CoiUrol 



with some sub-nodes of name, departmcnl, role name, elc. In the real world, 
user-role assignment is buill on organization structure, maybe be ccwpcrated by 
some department other than security administrator [3]. So the UR.xml may 
be derived from other systems. This is out of the range of this paper. What 
we present here are ail very high-level and conceptual. In the next step of this 
work, we will enrich and finalize the details of this algorithm. Schemas for 
UR.xml. PR.xml, RH.xml, and SSOH.xml will be defined. Since input 
and output in the algorithm are all XML documents, open source XML APIs 
will be applied, such as SAX (Java implemented XML parser). 
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Figure 4. PR.xml Example 



5. Related Work 

E.Damiani el aJ. [6] aiul E.Bertino el al, [7, 8] did some work in XML 
document access control, which is close to our work. E.Damiani el al, used 
organizalion-level DTD and site-level DTD as objects, built access control 
model for XML d<x:umenl based on authorization rules of (suhjecf, object, 
permission, recursive). They only considered read operation in the pa- 
per, The algorithm to cx^mpute the final view of XML document based on the 
subject’s authorization rules is presented with DOM tree labelling and trans- 
formation, E.Bertino et al, provided XML docniment access control policies, 
m<xlel and implementation based on authorization built on DTD and XML doc- 
ument. The authorization propagations from element-Uvsubelement. element- 
to-attribute, DTD-to-instance were considered with recursive options. Based 
on this, a Java-based access cx^ntrol system, named Author-X« implemented 
with discredorxary access cx^ntrol (DAC) model. Both Damiani and Bertino’s 
models are based on DTD, using the relationship between XML instance docu- 
ment and DTD to transport authorizations. Another point is that they used DAC 
model. The main difference between our work and these previous work is that 
we use RBAC model based on XML Schema. The user-role and permission- 
role greatly will improve the security administration with vast users and XML 
objects. Also, the schema based permission and permission reuse enable mod- 
ular and reusable policy deployment. Another point is that our model is not 
only for static XML documents, but for dynamically generated XML mes- 
sages. such as SOAP and other XML protocols. 
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From industry, mainly there are two projects on XML security motivated by 
Organization for the Advancement of Structured Information Standards (OA- 
SIS): Security Assertion Markup Language (SAML) [13] and extensible Ac- 
cess Control Markup Language (XACML) [14]. The motivation ot SAML is 
to define "assertion’* for security statements in XML, such as authentication 
and authorization. Some XML protocols have been specified in SAML to ex- 
change assertion in distributed environment. Our framework is orthogonal to 
SAML, Actually we will use SAML mechanism in our architecture. As shown 
in Figure 2, all XML requests and responses will be implemented in SAML 
messages and protocols, XACML is similar to our work, which applies XML 
format to specify access control policy with objects identified m XML. The 
mam difference is that XACML focus on policy level, including logical pred- 
icates, rules, and policy combining. So in XACML, there is no clear access 
control model supported. In our model, we focus on model level, A XML- 
based RBAC model is clearly supported, which is policy neutral. 

6. Conclusion and Future Work 

This paper presented an extended RBAC model for XML security. Per- 
missions in the model are defined ha.sed on XML Schema components and 
will be transported to all instances. Different from the previous access control 
model built on DTD. complex object hierarchies can be achieved with rich re- 
lationships between schemas components. The permission reuse through these 
hierarchies greatly improves the security administration by modular, reusable 
and extensible permissions. Several constraints are presented in the model. 
The proposed model can be modularly deployed and flexibly administrated in 
distributed environments. The model can be applied to no-schema ba.sed XML 
instance and instance level authorizations easily. The abstract implementation 
architecture is presented. 

The detail implementation of proposed model is the next step of this work. 
XML technology is applied in the implementation mechanism. The modu- 
lar and reusable features of XML will be the benefiLs to the RBAC model. 
SAML will be applied in our implementation for all XML messages. In the 
future we will study the access control in Web Services technologies, where 
the applications are built from XML protocols. As a service-oriented software 
environment, Web Services have roles like service provider, registry, requester, 
deployer, as well as system administrator. The schema based RBAC model can 
be a solution of Web Services security. 
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Abstract Various rolc-ba«d access control (RBAC) models have evolved along 
with a small number of imple mentations. One approach is to make 
role assignment persistent. After authentication, a principal can exer- 
cise the privileges associated with the roles it is assigned to without 
further action. Another approach is that principals must activate roles 
explicitly when they need to exercise the privileges associated with the 
roles. In this paper we outline our models and implementations (PER- 
MIS and OASIS), which provide an example of each style of system. 
Both are concerned with realistic implementations in large-scale, widely 
distributed systems. We discuss the advantages and disadvantages of 
persistent ver.sus dynamic role membership. 

Keywords: role-based access control, access control policy 

1. Introduction 

Access control is a crucial aspect of most computerised systems. Manda- 
tory schemes have been established for military contexts, and discre- 
tionary schemes arc associated with the design of most operating sys- 
tems. When distributed systems were first designed, based on emerging 
local area network technology, encryption-protected, capability- based 
access control was often used. Over the years this approach has grown in 
popularity as systems have become larger and more widely distributed. 
The capabilities have become encryption protected authorisation cer- 
tificates managed by service providers, often alongside authentication 
certificates and integrated with a public key infrastructure. 

Managing the access rights of principals to objects becomes increas- 
ingly difficult as individual systems grow in size and different systems 
need to interoperate. The privileges associated with a role arc largely 
independent of the principals who may currently fill that role, and these 
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privileges change slowly as an organization evolves. This is the key idea 
behind rolc-bascd access control (RBAC). in which privileges arc av 
signed to roles rather than to individual principals; that is, the service 
developer specifies axess control rights in terms only of roles. There arc 
usually many fewer roles than principals in an organisation, although 
a large organisation may have several thousand roles. RBAC therefore 
promises to be an appropriate access control scheme for large-scale sys- 
tems. When RBAC is used, administrators register principals in the 
usual way, as students, employees etc. It remains to express and enforce 
the policy that entitles principals to roles. 

An additional requirement for managing access control in widely dis- 
tributed applications is that heterogeneous, independently developed 
and administered systems should interwork; that is, principals managed 
by one system will need to use the services of others. Access to such priv- 
ileges must be negotiated between the systems. Examples arc services 
associated with e-government, where police, social services or health 
trusts may be authorised to access certain electronic records managed 
by another agency. Within the health application, the electronic health 
records of an individual patient may be shared between management 
domains such as primary care practices, hospitals, clinics etc. 

Various RBAC models have evolved over the years, for example. 
[8. 9, 12] but there arc few architectures and implementations. If RBAC 
is to he adopted in practice, large-scale engineering issues must be ad- 
dressed. one of which is the persistence of the binding of principals to 
roles. Most of the RBAC models assign principals to organisational 
roles for an indefinite period. The alternative is that a principal acti- 
vates a role only when it needs to carry out some task for which the 
privileges associated with the role are needed. In Section 2 we evalu- 
ate the approaches in principle then describe two implemented RBAC 
schemes. PERMIS in Section 3 and OASIS in Section 4. PERMIS uses 
persistent role-assignment. OASIS uses dynamic role activation, which 
we shall call P-RBAC and D-RBAC for brevity. In Section 5 we revisit 
the two approaches, highlighting the differences that remain significant 
after design decisions have been taken. We conclude in Section 6. 

2. Dynamic versus persLstent role membership 

We aim to evaluate persistent versus dynamic role activation in the 
abstract and in practice, to the extent that our early implementations 
allow. Figure 1 gives an abstract architecture for a single service (a) 
when role membership is persistent (P-RBAC) and (b) when roles must 
be activated explicitly at the time the service is to be used (D-RBAC). 
Let us assume that P must be a member of role R in order to have the 
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privilege of invoking service S. Aulhenlication requirements are common 
to both approaches; lei us assume it is carried out by some standard 
mechanism such as challenge-response. 



(4) rRBAC 









{b) D>RBAC 



f»i3 



















Figure J. A «rvice archiiec»ure wiih (a) persisienl and (b) dynamic rcle activaiion 

In (a) principal P’s right to role R must be established before service S 
can be invoked by P. Checking of role membership may be carried out as 
part of access control; either by checking an administrative database that 
associates roles with principals or by checking a directory in which some 
form of signed role membership certificate can be associated with P; 
both are so-called “pull" approaches and require that P is authenticated. 
Alternatively, P may keep its role certificate for R in its private file space 
and may present it to S as a parameter on invocation, a “push" approach. 
If flexibility is required over whether pull or push will be used in a given 
implementation then some form of encryption-protected role certificates 
must be used. Note that environmental checks may also be made as 
part of access control; these include time of day and facts that might be 
looked up. 

In (b) P must first activate role R by establishing its right to R ac- 
cording to R's activation policy. The role activation service may look 
up (pull) P’s credentials or P may present (push) them. In both cases 
the service will authenticate P, to prove its ownership of them. If the 
credentials satisfy the role activation policy, the service will record that 
P is active in role R and may also issue a short-lived role certificate to P. 
When P invokes S, either P presents the role certificate as a parameter 
and/or the service checks with the role activation service that P has 
activated role R. Again, environmental checks can be made as required 
by role activation and service invocation policy. 

2.1. Criteria for comparison 

Some criteria for comparison and issues that must be addressed by the 
two approaches are listed below. Later we show how the design decisions 
taken in PERM IS and OASIS address these issues. For simplicity of dis- 
cussion. we assume that role certificates arc cryptographically signed or 
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protected by encrypted communication. An alternative is to query se- 
cure administrative databases for the information. 

Role allocation and activation overhead 

In P-RBAC principals persistently hold their maximum number of roles; 
including those inherited by means ofRBAC delegation hierarchies. Cer- 
tificates are issued at a coarse time-grain, e.g. annually, to all principals 
entitled to them and may be used on many occasions. Many role cer- 
tificates may never be used. 

In D-RBAC roles arc aedvated at need according to role-activation pol- 
icy. It is likely that only a small proportion of principals and roles will 
be active at a given time. 

The overhead of certificate issuing is therefore a choice between pro- 
ducing large quantities of long-lived ccrdficatcs, which can be done in 
batch, offline or background mode (P-RBAC), or producing small quan- 
dties of short-lived certificates in the context of a working session (D- 
RBAC). The tradeoff is application-dependent and the certificates may 
not be equivalent, D-RBAC certificates may be passed, unsigned, under 
encrypted communication, for example. 

Credentials 

In P-RBAC, a principal's right to a role may be proved oncc-for-all when 
the role is first issued. Even paper-based credentials arc feasible since 
the role certificates are issued in background mode. In D-RBAC, en- 
titlement of a principal to a role must be proved by electronic means: 
ceitificates, smartcards or database records. 

Privacy 

Some methods of persistently recording principals’ assignments to roles 
might be considered an invasion of privacy for some applications. 

Authentication 

Both dynamic and persistent RBAC are authentieation agnostic and 
specific implementations may adopt whatever means arc appropriate. 
Note that some systems (Akcnti, CAS) mandate the use of PKIs for 
authentication so that roles can be linked to the principal's public key 
rather than to the principal’s identity. 

Policy expression, enforcement and evolution 
P-RBAC and D-RBAC are equivalent with respect to authorisation pol- 
icy. The policy that entitles principals to roles must also be expressed 
and enforced in both systems. In P-RBAC, this policy is applied stati- 
cally. perhaps by a human administrator, and certificates arc issued. In 
D-RBAC, the policy is enforced on role activation. 

Policy may require that certain checks must be satisfied, such as 
time of day, course work deadlines, relationships between parameters e.g. 
doctor-patient, and individual exclusions e.g. “all doctors except Fred 
Smith may read my health record". In P-RBAC assignment of prinei- 
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pals lo roles is static but environmental checks can be made on service 
invocation. In D-RBAC environmental checks can be made both on role 
activation and on service invocation. 

Policy will evolve over time, dictated by local and external require- 
ments, and it seems that these changes can be effected more immediately 
by D-RBAC, There is a need to manage policy change: to control access 
to policy itself and to ensure consistency as it evolves. 

Vulnerability 

At first sight it seems that P-RBAC may be more vulnerable to cryp- 
tographic attack than D-RBAC. However, the general issue of security 
of credenuals applies to both schemes, involving properties such as the 
algorithms used and the length of encryption keys. The time available 
to an attacker should not be an issue if the encryption mechanism is 
designed well. Vulnerability is more likely to result from theft of keys 
and certificates. Both approaches are likely to use some long-lived cre- 
dential, such as a public -private key -pair, for authentication at the start 
of a session. Vulnerability can be minimised by using session keys in- 
stead of persistent keys wherever appropriate, for example to identify a 
principal within a session. 

Revocation 

This is a crucial issue for P-RBAC and its importance for D-RBAC de- 
pends on how long roles arc active. Because few, known principals and 
roles arc active at any time in the latter, revocation seems to be more 
manageable for it. 

Distributed domains 

The single-service architecture shown above will in practice require ex- 
tension to a system of many domains, each comprising many services; 
for example a national EHR service comprises many primary care prac- 
tices. hospitals, clinics etc., each with many internal services. A service 
in some domain must be able to indicate, in its authorisation policy, a 
role defined in another domain, according to some negotiated agreement, 

3. PERMIS overview 

PERM IS is a role-based access control infrastructure that is based 
on standards and driven by policy. Roles arc allocated to principals by 
authorised managers and arc held in X.509 attribute certificates. PER- 
MIS has implemented hierarchical RBAC [5). so that a principal who 
is allocated a superior role will inherit the privileges of all subordinate 
roles in the role hierarchy. PERMIS has taken a very liberal view of 
what may be classified as a role. A role is defined by a value of any 
type (i,e. an attribute in X.509 terminology). So a classical role such as 
manager, supervisor or employee may be assigned to a principal and, in 
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addition, an application-specific status such as Frequent Flyer Gold, Sil- 
ver or Bronze. PERMIS provides a Privilege Allocator tool that allows 
its user to allocate attributes to principals, and to sign the attribute 
certifieatcs generated with his private key. 

Each attribute certificate contains the X.500 distinguished name of 
the principal (or a pointer to its public key certificate), the attributes 
(roles) allocated to the principal, the validity period of the certificate, 
and various other parameters that may limit the applicability of the role 
assignment. The top level allocating authority is known as the source 
of authority (SOA) for the embedded attributes. The X.509 standard 
also specifics mechanisms to control the delegation of authority from the 
SOA to subordinate attribute authorities, but delegation of authority is 
not fully supported by the cunent PERMIS implementation. 

3.1. PERMIS Architecture 

The integrity and authenticity of attribute certificates are protected 
by their digital signatures, so they can be stored anywhere without fear 
of their being modified without detection. Privacy protection is not 
however provided, so roles of a sensitive nature should not be stored in 
public repositories, PERMIS has chosen to store the attribute certifi- 
cates in LDAP directories by default, since LDAP is a popular Internet 
standard for accessing repositories, and the X.500 standards provide for 
this. The Privilege Allocator tool can be configured with the URL of 
an LDAP server, and it will write the attribute certificates directly into 
the principals' LDAP entries. 

PERMIS has been built to support the “pulf'or ‘'server pull” model of 
operation, in which the access control engine pulls a principal's attribute 
certificates from the LDAP directories whenever it needs to make an 
access control decision. PERMIS can also support the “push” or “user 
push model” of operation, in which the principal (or his agent) pushes 
the attribute certificates to the axess control engine whenever a decision 
is needed (Note that the current rclca.se of PERMIS has not implemented 
the push model fully since it docs not check certificate revocation lists, 
but we plan to add this in a subsequent release.) 

The access control engine has been built according to the ISO Access 
Control Framework (ISO 10181-3) [10]. This splits the access control 
functionality for an application into two components: the Access Control 
Enforcement Function (AEF), which is application- specific, and the Ac- 
cess Control Decision Function (ADF). which is application-independent. 
This architecture ensures that axess control decisions within a domain 
can be consistently enforced by the ADF independently of the applica- 
tion, so that all ADF decisions arc based on the access control policy 
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specified for the domain. To support this, PERMIS has defined its own 
policy grammar (sec next section). Each policy of the domain is se- 
cured in a policy attribute certificate, digitally signed by the SO A for 
the domain, and stored in the SOA's LDAP entry (each policy is given 
a unique object identifier according to the ISO ASN.l standard). The 
ADF has been built using Java, and an API has been defined to link the 
AEF to the ADF, This API comprises three calls (GetCreds, Decision 
and Finalise) and a constructor. When the ADF is constructed, it reads 
in the policy for the domain, checks that it has been signed by the SOA 
for the domain, and that it is the correct policy. Because the AEF and 
ADF are designed to run as one process, linked via the Java API. there 
is no need for them to authenticate each other. If they were to run on 
separate systems with a standalone ADF contacted by multiple AEFs, 
as in Akenti. then mutual authentication would be necessary. The al- 
ternative PERMIS approach is that the ADF runs together with the 
AEF on each system, and all the ADFs read in the same policy for the 
domain. 

When a user wishes to access an application controlled by PERMIS, 
he or she must first be authenticated by the application specific AEF, 
PERMIS has been built to be authentication agnostic. For example, 
when authenticating a user the AEF could use digital signatures, Ker- 
beros. or even uscrnamc/password pairs. This is an application specific 
choice. The only requirement that PERMIS makes is that the princi- 
pal’s distinguished name is passed to the ADF via a call to GetCreds. 
thus starting a new session. In pull mode, this causes the ADF to re- 
trieve all of the user's attribute certificates from the set of configured 
LDAP servers. In push mode, the set of ACs is passed at the time of the 
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call to GctCrcds. GctCrcds validates the user’s attribute certificates, 
disearding any that violate the domain policy, or that have expired, or 
that have been revoked (in a subsequent release). In addition, any un- 
recognised or invalid roles/attributes embedded within valid attribute 
cerrifleates are discarded. When GetCreds has finished, the ADF is left 
with a set of valid roles that conform to the policy of the domain, and 
these roles will be used for the duration of the user’s session. 

Whenever an access request is made by the user, the AEF asks the 
ADF to make a granted or denied decision, based on the policy, the 
target name and the access parameters. In addition to the static policy 
elements described in Section 3.2 PERM IS includes a plug-in feature 
so that application specific condition-evaluation objects can be invoked 
during decision making. Each request that is granted will be passed to 
the target, whilst each request that is denied will be rejected, 

A specific policy is bound to the ADF when it is first constructed. If 
it is necessary to introduce an alternative policy while an application is 
executing, the application can destroy the current PERMIS ADF object 
and construct a replacement, PERMIS also supports an application- 
defined event object that is called back from the ADF, This allows the 
AEF to prematurely terminate a user session, for example if the session 
has been open too long. 

3.2. The PERMIS Policy 

The PERMIS RBAC Policy (6) comprises the following components: 
SubjeciPolicy - this specifies the subject domains covered by this pol- 
icy. Each domain is specified as an LDAP subtree. Only principals with 
an LDAP distinguished name that falls within a subject domain may he 
authorised to access targets covered by this policy. 

RoleHierarchyPolicy - this specifics the different roles supported by 
this policy, and their hierarchical relationships to each other. 

SOAPoUcy - this specifics which SOAs arc trusted to allocate roles. 
The first SOA in the list is the SOA for this domain (and is the one 
which signs this policy). Subsequent SOAs in the list are remote SOAs 
which arc trusted by the local SOA. This delegates authority to remote 
SOAs. so supporting distributed role management. 
RoleAssignmentPolicy - this specifies which SOAs may allocate which 
roles to which subjects, whether further delegation of roles may take 
place, and for how long the roles may be assigned. This sub-policy ef- 
fectively states who is trusted to allocate which roles to whom, and is 
central to the distributed management of trust. 

TargetPolicy - this specifics the target domains covered by this policy. 
Each domain is specified as an LDAP subtree. Only domains with an 
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LDAP distinguished name lhal falls within a laigcl domain arc covered 
by this policy. 

ActionPolicy • this specifics the actions (or methods) supported by the 
various target domains, along with the parameters that should be passed 
along with each action, e.g. action Open with parameter Filename. 
TargetAccessPolicy • this specifies which roles may perform which 
actions on which targets, and under what conditions. Conditions are 
specified using Boolean logic and may contain constraints such as “IF 
time is GT 9am AND time is LT 5pm OR IF Calling IP address is of the 
form 125.67.X.X". All actions that arc not specified in a Target Access 
Policy arc denied. 

4. OASIS overview 

Oasis is an access control system for open, interworking services in 
a distributed environment, with services being grouped into domains for 
the purpose of management. Services may be developed independently 
but service level agreements allow their secure interoperation, OASIS is 
closely integrated with an active, cvent-based middleware infrastructure. 
In this way we can notify applications of any change in their environ- 
ment, making it possible to ensure that security policy is satisfied at all 
times. Oasis is role based but has important differences from other 
RBAC schemes [5, 8. 9. 12]: 

• Roles arc service- specific; there is no notion of globally centralised 
administration of role naming and privilege management, 

• Roles may be parametrised, as required by applications. 

• Roles arc activated within sessions. An OASIS session is started 
by strong authentication of a principal, and an initial role such as 
log^ed_in_u<:eris> created as a side effect of authentication. Roles 
have activation conditions that may include the requirement for 
prerequisite roles; a dependency tree of active roles is built up 
within a session, 

■ Persistent credentials (as opposed to session-limited RMCs) are 
implemented as appointment certificates, which do not confer priv- 
ileges directly; the activation conditions of roles may include ap- 
pointment certificates. We use appointment instead of delegating 
roles or privileges. 

• Role activation conditions can also include constraints on the con- 
text, which must be checked during role activation. 

■ We provide an active security environment. Certain role activation 
conditions arc specified as having to remain satisfied for the role 
to remain active. These arc monitored and a role is deactivated if 
any becomes false. 
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Figure 3 Oasis role activation within a scission 

An overview of OASIS is given in [1. 2), details of its architecture and 
engineering can be found in [3] and a formal model is presented in [4J. 
In this paper we focus on the implications of dynamic role activation. 
Figure 3 gives an example of a role activation rule. In order to activate a 
certain role of service B the principal must have activated two specified 
prerequisite roles (another role of service B and a role of service A); it 
must present a persistent credential (an appointment certificate) as proof 
of some long“lasting employment or qualification; and two environmental 
constraints must be satisfied. One concerns the time at which the role is 
activated, the other requires the administrative database to be consulted 
to determine, for example, some valuc(s) of or relationship between the 
parameters of the role (not shown). If these conditions arc satisfied the 
new role is activated, and a role membership certificate (RMC) returned 
to the principal, A new credential record (CR) is set up by service B to 
record the status of the role that has been activated. 

Certain role activation conditions arc flagged as membership con- 
ditions, that is, they must remain true for the principal to remain active 
in the role. An event channel is set up associated with each of the mem- 
bership conditions. Should any become false, this is notified immediately 
to the service that has issued the RMC. 

Service level agreements are made to allow principals to invoke ser- 
vices in remote domains from their home domain, or while working tem- 
porarily in the remote domains [3]. For example, a hospital doctor may 
use a national EHR service or may arrange to work temporarily in a 
Research Clinic. 
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In our current, web-based implcmcmalion, sessions and client RMCs 
arc managed al a web portal under SSL (secure socket layer), X.509 
certificates arc used for appointments. 

4.1. Appointment 

Instead of delegating roles or privileges, and to capture long-lived 
certification of academic qualification or employment, OASIS uses ap- 
pointment. A function of some roles is to issue appointment certificates 
to other principals. Appointment certificates in themselves convey no 
privileges but may be required by policy as credentials, alongside envi- 
ronmental constraints and prerequisite roles, to activate certain roles. 

For example, a professional society or academic institution may issue 
appointment certificates to people who become professionally or academ- 
ically qualified. At present a paper certificate is typical, backed up by a 
database record at the issuing body. Such certificates may be required 
credentials for activating certain roles; for example, to be a member of 
an appeals panel at the society or institution. 

These certificates may be conditions of employment, such as when 
a doctor is employed at a hospital. Instead of requiring academic and 
professional certificates in the activation rules of roles in the hospital, it is 
preferable for the hospital to issue an appointment certificate indicating 
“employed as doctor” after the professional and academic qualifications 
have been validated by the issuing bodies. The internal roles of the 
hospital need then only require the local “employed as doctor” certificate 
among their activation rules. This long-lived style of credential may be 
seen as augmenting a database record. The certificates may be issued as 
machine -readable cards or may be stored in private or public directories. 

Appointment may also be used in situations where a technically- 
qualified stand-in is required; perhaps someone is called away in an 
emergency and must arrange a substitute. Here, the appointment cer- 
tificate is unlikely to be long-lived, but its lifetime is not restricted to the 
session in which it was issued. The receiver may use the appointment 
certificate to activate appropriate roles within its own sessions. 

5. Persistent versus dynamic role membership 

We now revisit the issues introduced in Section 2 in the light of the 
design decisions taken in PERMIS and OASIS, The implemented sys- 
tems are closer in functionality than we expected; for example. PERMIS 
requires roles to be used within sessions and checks role activation policy 
at the start of a session. 

This study has made us rcaiisc that we have different intuitions about 
what a role is. In PERMIS roles are generic categories, such as doctor, 
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whereas OASIS deems these to be appointments, that is. credentials 
for aetivating service-specific, parametrised roles when the need arises. 
Examples of roles in OASIS are doctor-on-duiyiDr-lD), an initial role 
requiring strong authentication and an employed-os-dociotiDr-ID) ap- 
pointment credential, and treutmg'docioriDr-lD. paiienh/D). a role re- 
quired because only a doctor with whom a patient is registered is permit- 
ted to read that padent’s health record. Role activadon policy is likely 
to require a docior^on-duiy prerequisite role and parameter lookup in an 
administrative database to check the doctor-patient relationship. OA- 
SIS was designed to capture fine-grained, service-specific policies. 

Role allocation and activation overiiead 

Neither implemented system has yet dealt with large numbers of prin- 
cipals and roles e.g. millions of principals and thousands of roles. 

For the applicadons to date, the overhead in PERM IS (P-RBAC), of 
issuing X.509 role certificates to all principals for all the roles to which 
they arc cndtlcd has been manageable. A Privilege Allocator API al- 
lows attribute ccrdficates for all principals to be created automatically 
from a back-end administrative database e.g, to create “doctor'* roles 
for everyone registered at the General Medical Council, It would not be 
feasible to create statically the parametrised, service-specific roles envis- 
aged by OASIS, for example a dociorfDr-JD. patient- ID) role for every 
patient of every doctor. 

Allocation and management of OASIS persistent credentials (long- 
term appointment certificates) involves an overhead comparable with 
allocadon of role certificates in P-RBAC. although database lookup can 
replace the asc of appointments in any implemcntadon. Both systems 
allow certificate allocation to be partitioned between different sources 
such as professional bodies and academic institutions, OASIS envis- 
ages that some generic employment categories, such as doctor or consul- 
tant, will be defined in local domains and appointment certificates will 
be issued on employment, thus subsuming externally issued credentials, 
some of which may continue to be paper-based. Short-term but session- 
independent appointment (to enable the delegation of a role) is likely to 
be used on a small scale. 

Privacy 

In the PERM IS pull mode persistent role certificates arc stored in pub- 
lic LDAP directories, which potentially compromises the user’s privacy. 
If privacy concerns arc paramount, then P-RBAC should use the push 
model and allow the user or Attribute Authority to hold and control the 
rclea.se of his certificates across a confidential channel. The downside of 
allowing the user (rather than the AA) to control his role certificates 
is that revocation checking must now be carried out by the ADF, In 
D-RBAC the role certificates arc not publicly visible when issued or 
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presented and pass within communications that arc encrypted under 
SSL. Thus privacy is ensured. 

Vulnerability 

Both projects lack experience over a long term of deployment. Both are 
using standard PKl services: SSL (OASIS), X.509 certificates for roles 
(PERMIS) and appointments (OASIS), 

Revocation 

D-RBAC does not necessarily need a revocation mechanism because the 
roles, and therefore the privileges, arc short-lived. But since only a rela- 
tively small number of principals are active at any time, it is practicable 
to have role membership rules (that indicate which role activation con- 
ditions must remain true for the principal to remain active in the role) 
and to monitor that they remain satisfied. Immediate revocation of role 
certificates is part of the OASIS scheme, effected by invalidating the cre- 
dential record for the RMC, and notifying any service that has cached 
its validity and requested call-back. 

In P-RBAC it is not feasible to monitor every persistent role cer- 
tificate in a system continuously, but this is not required, since only 
currently active certificates need to be monitored. In PERMIS initial 
monitoring is done at session initialisation time, by cither retrieving the 
latest certificate revocation list or issuing an OCSP (online certificate 
status protocol) [11] request. Continuous monitoring could be achieved 
by using a protocol such as OCSP, requiring OCSP queries to the OCSP 
server immediately prior to each access control decision, but this would 
be inefficient. It should be necessary only for transactions where the loss 
associated with accepting a transaction, for a role certificate that has 
been revoked after initial monitoring, is high. Instead. PERMIS has a 
callback procedure that allows the AEF to terminate the user's session 
prematurely in an application-specific way. 

Ease of use 

The PERMIS P-RBAC pull model is easy for the principal to use. since 
he does not need to know about his role certificates or where they arc 
stored. The service will pull them from the public repositories. The 
principal only needs to know how to authenticate to a particular ser- 
vice. Tlie PERMIS push model requires the principal or his A A to 
know about and to actively manage his role certificates. 

The current OASIS implementation, for a web service environment, 
requires OASIS services and user agents to have PKI facilities. The 
web portal acts as session manager. For a given authorisation policy it 
acquires the necessary roles on behalf of the user (validating each role's 
activation policy) and presents role certificates under SSL, 

In both systems, policy is specified by the service developer and may 
include environmental checks with application and/or domain databases. 
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As noted above. PHRMIS and OASIS roles differ and there inay be a 
tradeoff between simplicity of policy expression and express) vcncss/flexibility. 

6. Conclusions 

Please sec our websites for the original paper presented at the con- 
ference . Space constraints do not permit a full discussion here. In sum- 
mary. we believe that the important design decisions for the future will 
be concerned with scalability and the expression, enforcement and man- 
agement of complex, evolving, distributed policy. Acceptance by users, 
application developers and administrators wili be cridcal. Neither sys- 
tem has yet been tested on a realistic scale, for example associated with 
nationwide systems comprising millions of principals, thousands of do- 
mains and many thousands of roles. We look forward to gaining experi- 
ence from the use of our implementations in large-scale applications. 
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Ahsiraci We propise Flexflow, a logic based flexible flo* cx>nirol framework to specify 
daia*floWs work-flow and iransaciion sy&iems policies iha( go beyond poini-io- 
poini flows. Bolh permissions and prohibilions are specifiable in FlcxFlo* and 
meia-policies such permissions take precedence ihemselves can be specified 
over the meia-policy neutral policy specification environment of FlexFlow. We 
show (he expressibiliiy of FlexRow by expressing three existing flow control 
models which were pressed for different applications and used different mech- 
anisms. 

Keywords: Flow control policy. Data flow, Security policy 

1. Introduction 

Information flow policies govern the exchange of information at various 
levels in systems. At the lowest levels, information is copied in and out of reg- 
isters and memory locations inside processors. At a higher level, information 
is exchanged among variables in programs, methods in object oriented sys- 
tems and transactions in database systems. In networked systems, messages 
are copied across system boundaries in order to exchange information. In all 
of these examples the levels at which information flows, the units of trans- 
fer and the number of destinations vary, but the central issue of information 
flow remains the same. Thus, it is intcresdng to investigate the commonalities 
among policies that govern information flow at an abstract level. This paper 
proposes FlexRow, a framework to do so. 

Being designed to capture properties common across flows, RexFlow is for- 
mulated using abstractions of nodes and trees of flows among them. Because 
of this abstractness, RexRow has two advantages. Firstly, RexRow is not 
limited to high or low level information exchange policies. Thereby it can be 
used to reason about and derive consequence of mixing flow control polices at 
different levels. For example, higher level information exchange policies may 
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govern flows bclwccn method calls, and lower level policies may govern data 
flows inside method ealls. Because our framework can model information flow 
at both levels, it is able to combine policies across both of them. 

The second advantage is that our policy specification framework docs not 
depend on any meta policies. Therefore, policies using different meta policies 
can be modelled and their total effect can be compared using our framework. 
This is similar to the advantage gained by the Flexible Auifu)ri:t3fton Frame' 
work (FAF) of Jajodia et al. [9] over its predecessors in specifying access con- 
trol policies, 

FlcxFlow specifics flow control policies as a set of stratified Horn clauses, 
which is sound and complete, in the sense that every requested flow is either 
granted or denied, but not both. FlcxFlow is based on unique stable model 
semantics, and therefore FlcxFlow rules can be interpreted unambiguously. 

The rest of the paper is organized as follows. Section 2 informally intro- 
duces abstract concepts of nodes, flow trees and their representations. Section 
3 formally describes the FlcxFlow framework. Section 4 shows that FlcxFlow 
can be ased to express various existing flow control models. Section 5 de- 
scribes related work and Section 6 concludes the paper. 

2. An Informal Description of FlexFlow 

This section informally describes the FlcxFlow framework and the reasons 
that went into making our design choices. FlexFlow has trees referred to as 
flow trees build up from nodes and branches. Nodes represent sources and 
sinks of information and branches represent pathways taken by information 
flowing between nodes. Thus, information flows from the leaves of a tree 
via intermediate nodes to its root. Given that the same node can either send 
information or refuse to do so under different circumstances, FlcxFlow uses 
node environmenis to capture sufficient data to enforce such local decisions. 
Similarly, a flow tree itself may be acceptable or rcjcctable due to policies 
under different global circumstances, despite the nodes enforcing their local 
policies. Such circumstances arc captured by tree environmenis of flow trees. 
The exact relationship between the environment of a flow tree and those of its 
nodes is not rigidly fixed by FlexFlow and is therefore application specifiable. 
Consequently, the flow trees with their environments, consisting of nodes and 
node environments constitute the basic entities of focus in FlexFlow. In order 
to specify how to construct acceptable or rejectablc flow trees, FlexFlow has 
rules written in the form of Horn clauses about trees and their structural prop- 
erties, Our position • one that we pul forth in this paper • is that such rules 
suffice to enforce existing flow control policies in a uniform and incta-policy 
independent manner. 
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As an example, consider an abstract syntax tree of the expression x-\’(y’¥z). 
As shown in the left hand side of Figure 1 (the right hand side is its Prolog 
represenlalion • to be explained shortly), it consists of three leaves with vari- 
ables (variables arc considered named locations that can hold values) y and 
z, one intermediate node Rt^mp ^ root node Assume that each 

variable in this example is accessible by a specified set of subjects. For ex- 
ample, a: is accessible by Alice and Bob, 2 /^^t?ssiblc by Bob and Cindy, and 
Z accessible by Alice. Bob and Cindy. We model this situation by making 
the environment of each node be the access control list. We view each binary 
addition operation as a computation tree in which the root stores the sum of 
the values stored in the leaves. Thus, as shown in Figure 1 there is an inter- 
mediate node holding the value of x -Yy and the root R final holding 

* + (j/ + 2 )- As it is shown in Figure 1. R final holds the value of x + Rtemp- 
The tree rooted at Rtemp is said to resemble a one step flow, as it has depth 
one. By piecing together two trees with depth one, (namely the depth-one bi- 
nary tree rooted at rooted at ^ depth-two 

flow tree, namely the tree rooted at x, y and z as leaves. Having 
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Figure L An Example Flow Tree 



to reason with tree structures and lists in Horn clauses, FlcxFlow uses Pro- 
log’s list notation to represent trees, and uses ordered pairs of (node names, 
environments) as our nodes. For example, {z^ [Alice, Boh, Cindy]} repre- 
sents the rightmost bottom (i.e. the last in the in-order representation of the 
tree) node in Figure 1. And. [{Rtemp, Cindy]}, [(y, [Alice,Cindy]}, 

{Zy [Alice, Bob, Cindy]}]] represents the subtree rooted at Rtemp an ac- 
cess control list (Alice, Cindy j and two children j/and z. 

FlcxFlow states flow control policies as Horn clauses using flow trees as 
individual elements. In order to create these rules we used some predicates. 
Both rules and predicates used in FlcxFlow belong to a five level stratification. 
FlcxFlow use these stratified rules to specify flows that are permitted or pro- 
hibited without assuming any mcla policies such as the open or closed policy. 
Formal details arc given in Section 3. 
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2.1. Architecture of FlexFIow 

As shown in Figure 2, FlcxFlow ruJes have five stages, numbered zero 
through four in the figure. The first of them is the structural module (stage 0) 
eonlaining data structures and functions needed to define flows. These include 
subject and object hierarchies, predicates necessary to model the environments 
and list manipulation operadons such as adding or removing elements, taking 
the union of two lists etc. 




Figure 2. FlcxFlw Sy^iem Archiieciurc 



Stage 1 is used to specify one-step flows that arc permitted or prohibited 
ba.sed on the structural properties specified at the previous stage. Stage 2 is 
used to build permitted or prohibited flow trees that may use already defined 
one-step flows. Recursion is allowed in this step. For cxajnple if flows arc 
transitive, they can be specified at this stage, as transitive closure can be defined 
recursively. Similarly, permissions can be propagated up and down subject, 
object and role hierarchies using recursive rules. 

Although propagation policies arc flexible and expressive, they may result 
in over specification. That is, rules could be used to derive both negative and 
positive flows that may be contradictory. This possible conflict is due to the 
fact that positive and negative permissions is an application level inconsis- 
tency. This kind of inconsistency is not recognized by the underlying stable 
model semantics of locally stratified logic programs. Similar encodings have 
been used in the Flexible Authorization Framework by Jajodia ct al. [9|. In or- 
der to weed out eontradiedvc specifications. FlcxFlow uses conflict resolution 
policies. They are stated in stage 3. 

At stage 4. decision policies are applied in order to ensure the completeness 
of flow specification. That is because every flow request made to FlexFIow 
jnust be cither granted or denied. This is necessary because, as otherwise the 
framework makes no assumption about flows that arc not derivable only using 
stated rules. 
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3. Syntax and Semantics of FlexFlow 

3.1. The Language of FlexFlow 

Teims of the language: The language of FlexFlow consists of terms that are 
made up from constants and variables for nodes, environments and aetions. It 
also has constants and variables over lists of (node, environment) pairs. Sueh 
lists arc considered as flow trees, where the first element is the root and the 
rest arc the children. In addition. FlexFlow allows environments to have appli- 
cation defined structures and predicates. An example of such a structure is an 
access control list, as used in Figure 1 . 

Predicates of the language: Predicates in RexFlow belong to five strata, as 
summarized in Table 1 and explained below. 

Stratum 0: Consists of list manipulation and application- specific predicates. 
An example of an application specific predicate is rol0(x^,Xf) stating 
that subject plays role Xf. An example list manipulation predicate 
is lsM0mb©r{(a;rt»i*’e)i *he (node, environment) pair 

(in, is in the list Xi. More examples arc given in section 4. 

Stratum 1: Consists of a four-ary predicate safe Flow. The formal param- 
eters In, le. ^Action of SafeFlOW(ln. X^,XL,±Xacim) ^TC 

respectively the destination node, destination environment, a finite list 
of source (node, environment) pairs and a name for the one step flow, 
safe Flo W(a?ni ^ 9 * Xi, ±ioch<m) holds if the one step flow consisting of 
the source list Xi, and the destination named x^ction cither 

permitted or prohibited depending upon the sign (+ or •) appearing in 
front 

Stratum 2: Consists of a ternary predicate safe Flow*. The formal parameters 
®/IwTi ^action in SdfSROW 

respectively a flow uec, its environment X/iq^s and its name XacHon- 

a permitted or prohib- 
ited flow tree depending upon the sign (+ or -) appearing in front of 
Xactiofi' 

Strata 3 and 4: Consist of a ternary predicate finalsafeFlow, with the same 
arguments as safeFlow*. representing the flow control decisions finally 
made by RcxFlow. It is used to express conflict resolution policies. 
finalSaf0Flow(iyr<„»rT)J*^/lw£»+^<ict»(w») RexRow permits 

the flow tree x/io^t and is included in stratum 3. finalSafeFlowfi 
^flowBy ~X{iciion) holds when RexRow prohibits the flow tree Xfio^T 
and is included in stratum 4. 
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Table J. StniiAcaiion of PlexPIow and Picdicaiea 
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3.2. Rules used in FlexFlow 

A FlexFlow spccificalion consists of a finite set of Horn clauses (rules) con* 
slrueted using above jnentioned prcdiealcs. These rules arc consirueted so lhal 
they form a locally stratified logic program. Obtaining a locally stratified logic 
prograjn requires that ihc predicates used in ihc rules belong to a finite set of 
strata, and the rules follow some syntactic constraints. Generally, predicates 
in the body of any Horn clause arc from the lower strata than that of the head 
of the clause. The only exception to this rule occurs in stratum 2. where safe- 
Flow* is allowed to appear in the head and the body of a rule. Rules that 
permit the head predicate to appear in the body have to satisfy further syntac- 
tic restrictions that they form a local siraiificaiion. Namely, the occurrence of 
safeFlow* in the body cannot be negative. Logically, this restriction implies 
that every instance of the recursive rule can be unravelled in a finite nujnbcr 
of steps, where negation at any such unravelling is interpreted as failure over 
previous unravelling. FlexFlow is stratified by assigning levels to predicates as 
shown in Table 1 , and the level of a rule is the level of its head predicate. Now 
we explain rules at each stratum with some examples. 

Stratum 0: Rules in this stratum consists of basic facts related to application 
specific predicates and list processing functions. Following facts relate 
to the syntax tree example in Figure 1 . 

itEnv(x, 

^nv(Vi [Alice, Cindy] ) •— 
ia£nv (a , [AUce. Bob. Crndy]) ^ 

These rules state that the access control lists of variables x, y and z are 
[Alice. Boh], [Alice, Cindy] and [Alice, Boh, Cindy] respectively. 

Stratum 1: Rules in this stratum have literals frojn Stratum 0 in their bodies 
and heads that are instances of safeFlow. Example rules for the syntax 
tree example of Figure 1 is as follows. 

iaf«Flow(»n,*,,Xi,+Wnory^dd) Mn*on(({v,i»e)l, [(v.ve)|, Xt),li6nv(u,ii«), 

isEnv ) , intersection (ue , Ve , } 





364 



DATA AND APPUCA TIONS SECURITY XVil 



The rule says that il is safe for ihc source list Xi^io binary Add into the 
root (a?nt provided thatX^ has two elements (u, Ue) and(v, u«), and 
the environment ofxg is the intersection of access lists of the sources. 
This rule also uses the list processing predicates union(A,B.C), hler- 
section(A.B.C) that hold when C is the union/intersection of lists A and 
B respectively. 

Slralum 2: Rules in this stratum have literals from Strata 0 and 1 in their 
bodies and heads that arc instances of safe Flow*. Example rules for the 
syntax tree of Figure 1 are as follows. 

safeFlow(x n. > ((<*• u« }. (v, v« )I» *btnaryAd<If , 

3fe), ((u, Ut),{v. V«>1. **). 

»feFlew«(7( , Xt . +bTret) — $af«Flow • (7 1 , xe | . +6Tr«e), mtiBinTr«« (x i , xj, xt }, 

«f«Fk»w-(a 3 , union(x«, , Xe# * Xe) 

The first rule says that a one step flow tree is a safe flow tree. The second 
rule constructs larger flow trees from smaller ones. The larger tree is 
made by using the predicate mkB) nT ree, rtl kB I nTree (i 1 , X 2 , Xt) makes 
a binary tree xt with first and second children x\ and X 2 respectively. In 
addition, the environment of the new tree is the union of environments 
of the two trees used to make up the larger tree. 

Stratum 3: Rules in this stratum may contain literals from stratum 0 through 2 
in their bodies but only finalsafeFlow heads that have (+) action terms. 
They arc used to specify conflicts that arc resolved in favor of permis- 
sions. Example rules for the syntax tree of Figure 1 is as follows. 

(inalSafeFiow(7| ,x«, +t>Tr 2 e) •— aW«n)b«i‘(^t(ce, Xe}i tsM«mb«r(Oo4, 7e), 

ur«FI(M«(xe,x«» 

The rule says that a flow tree is safe provided that Alice and Bob are 
included in its environment. 

Stratiun 4: This stratum has one rule only. It is inserted by the FlexFlow 
system automatically to ensure the completeness . It reads as follows. 

final SafeF low( 2 t > ~ Xq etton ) '-'rinaiSafeF)ow(x < , x« » +Xae( wn) 

This rule says that permissions not derivable using given rules arc pro- 
hibited by the system, 

3.3. Semantics of FlexFlow 

The semantics of FlexFlow is given by the well known stable model seman- 
tics [8] and well founded model semantics [7] of logic programs. In fact, as 
we showed in Section 32. FlexFlow specifications are locally stradfied. This 
property guarantees that their stable model semantics is equivalent to their well 
founded semantics, thus ensuring that they have exaedy one stable model (this 
follows from a result of Baral and Subrahmanian (!]). 
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4. Using FlexFlow to Express Existing Flow 
Control Models 

This section shows how FlexFlow can express existing flow control models 
and Ihcir flow control policies. We choose three different models from previous 
literatures. Wc refer the reader to (3) for the reasons of our choice and the 
difference between the models and FlexFlow. 

4.1. The Lattice Based Flow Control Model of 
Denning [4] 

In (4], an information flow model FM is defined as < N,P,SCt 
where is a set of objects, P is a set of processes and 5C is a set of disjoint 
security classes. © is a binary operator on SC and — ♦ specifies permissible 
flows among security classes. That is, for security classes A and B, A — * 5 iff 
information in class A is permitted to flow into class B, Under some assump- 
tions. referred to as Denning's Axioms, < 5C, — > form a universally 
bounded lattice where < SC, — *> forms a partially ordered set. 

Suppose / is an n-ary computable function, and arc object belonging to 
security classes for all t < n. Then the flow control policy enforced by FM 
is as follows. If a value . . . , flows to an object 6 that is bound to a 
security class 6, then ® ® b must hold. 

To specify this flow control policy, we use the following sets. C is a set of 
classes. Obj is a set of objects. P is a set of processes. In this example, we 
use objects as nodes and classes as environments of nodes and the root s envi- 
ronment as the tree’s environment. In addition, we define application specific 
predicates shown in Table 2. For instance, dommate(c,c^) says that the class 
c dominates cla.ss c* in the class set C. The FM policy is now formulated as 
follows. 

7b6te Predicates used to express Lattice Based Flow Control Model 
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ftrtalSafeFlo«(X, «o, »- x« + 

The first two rules specify that Oj, 02 arc associated with C\ and ca respec* 
tivcly. The third rule says that cj dominate cj in C. The fourth rule is the 
transitivity of the dominance relation. The fifth rule says that information from 
objects in the list X is allowed to flow into Zo iff the least upper bound of the 
classes of objects of X is dominated by the class ofi(,. The sixth rule con- 
structs the depth-one permissible flow tree [(aicic) I «^| with environment Xc- 
Because the flow control policy in this lattice based flow control model has 
only one- step flows, we don't need to construct flow trees of depth greater that 
one. Furthermore, the model doesn’t allow negative permission, so the conflict 
resolution policy is simple and given by the last rule. 

4.2. The Decentralized Label Model of Mayer 
and Liskov [11] 

Ihc Deceniralized Label Model [11] of Mayer and Liskov is applied at the 
runtime data flow analysis level. This model has variables storing values and 
updating them during a computation, A label eontaias a list of owners whose 
data was observed in order to construct the data value in question. Each owner 
declares a set of principals that may read the value, referred to as the reader set 
of that owner. Each (owner, reader set) pair is said to constitute a pcr-principal 
flow control policy. When a value is read from a variable or an input channel, 
the value acquires the label of the variable or the input channel. When a value 
is written to a variable, a new copy of the value is generated with the label of 
the variable. 

The flow control policy used in this model is that when information flows 
from one object (here, object refers variable or channel) to another, the label 
of the destination must be more restrictive than the label of the source. A label 
Li is said to be more restrictive than label Lj iffLj contains all the owners of 
label Lj.and the same or fewer readers for each owner. 

To express the policies of |1 1]. we define Ohj, P and L as the sets of vari- 
ables, principals and labels respectively. We use variables (input and output 
channels included) as nodes of the flow trees and labels of variables as envi- 
ronments of the nodes. Before specifying flow control policies as rules, we 
define some application specific predicates as shown in Table 3. 

s»feFtow(x», *t. y, - tabel{ie, Zj), H«Om<JSei( V, Y'), «RdS«(z<. X), 

alllntenec( Y', tV), cov«r{X, W) 

I Y|,z,,+*aaic«) ^ 

tin»IS»feF tow(X, zi , ^Zsction ) «— sa feFlow*( X, si . +Zo«(«0n} 

The first rule says that information can flow from objects in the list Y to Xo 
provided that each of principals in the effective reader set of label xi can act 
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Table S. Predicated used to express Decentralized Label Model 
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for some principals in the inlerseedons of Ihc effective reader sets of labels in 
Y. The second rule constructs the depth one permissible flow tree. The third 
rule specifics ihe conflict resolution policy. 



4.3. The Flexible Information Flow Control 
Model of Ferrari et al. [5] 

This model provides an approach to control information flow in object* 
oricnled systems that takes into account, beside authorizations on object, also 
how the information has been obtained and/or transmitted. They coined a no- 
tation of transaction execution tree to represent the invocation relations of Ihe 
methods calls initiated by a user. Figure 3 gives an example transaction ex' 
ecufion tree simplified from the example in [5]. where each node is a cxecu* 
tion notated by execution id with the method name and the object on which 
it executed on. and each directed branch is caller-callee relation between the 
methods. 

Based on the transaction execution tree, they define that there is an informa- 
lion flow from to by and 6^, written Cfe, Ofc) if the method of 

is read, the method ofgj^ is write, and there is a transmission channel between 
eh and e*.. Ber example, there are four information flows in Ihe transaedon 
execution tree example we given, which are (03,e3,en,06)» (O4,e«,ei7,0fl), 

(os,ei3,cn,05),and 
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Figure 3. 



A Tran.saciion Execution Tree and its Flow Tree 
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In Ihcir mcxlcl, every object has an access control list (ACL) specifying the 
users allowed to read and write the object. Some methods arc associated with 
waivers. Two kinds of waivers arc supported: invoke-waiver (IW), specifying 
exceptions applicable during a method's execution, and reply (RW). specifying 
exceptions applicable to the information returned by a method. 

Based on the concepts of waivers, they consider each flow under the fol- 
lowing policy, referred to flexible policy. A flow is safe iff 

the union of the reader list and the waiver lists for along the transmission 
channel from o/j up to but excluding subsume the readers list of o*. The 
execution of a write method is said to be safe iff all flows ending at it arc safe. 

In order to express the flexible policy using FlexFlow, we first extract all 
flow trees from the transaction execution trees using an algorithm called flow 
tree generaro/[^]. Figure 3 shows a flow tree extracted from the example trans- 
action execution tree. We define four sets, Obj, U, M. E which arc sets of 
objects, users, methods and executions respectively. We also define some ap- 
plication predicates which arc shown in Table 4. Some of these arc not standard 
list manipulation predicates. Due to the space limitation we refer the reader to 
(3] for their definitions. Using these predicates some sample rules that fit in 
stratum 0 ofFlexFlew arc as follows. 

Predicates used to express the Flexible Flow ComroJ Model 
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rAd(Oj, \Ann, Bob, Carol, Davtd^) — 
rW(m9, (loi , Franfc], { 03 . Fronfc))) «- 
iWfmj , If tn , Oovirfl » (o« , Dav%4\] ) — 

fwFlowCH(e}4ie&) •— 

The first I WO rule specify that e% is a read method of 03. The third rule says that 
lAnn,Bob.Carol,David] is the read access control list of 0^. The fourth and fifth 
rules say that m3 *8 reply invoke waivers are [[o\, Frank], [0$, Frank]] 
and [(04, David], David]] respectively. The last rule says that there is a 
onc*sicp forward flow channel froincg tocj4. One-step information flows arc 
specified using the following two rules. 

, V, |(v«. v)f , +MCfcanneI) •— bkRowrCH (xa , ye ) 

lafeFlowfs^e , v, ((y« » v)j, + / ufCAannet) ^ fwFk»vCH (z« , ) 

The.SC two rules say that in order to have one-step forward/baclcward flow, 
there must be a one-step forward/backward channel from the source to the 
sink. Permissible information flow trees arc constructed using the following 
recursive rules. 



ufeFIOw«(|x«), |xo|X}, -Hi) 
»aW\Q*t*{Xfto^,X/te^e>+n) 
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The first rule says that executing a read method mconslmcls a one node flow 
tree that has [o, X\ as its environment where X is the ACL of o. Second and 
third rules recursively construets flow trees that have non-write roots. Note that 
for any node in any flow tree extracted from a given transaction execution tree, 
there is at most one forward channel feeding into it. The fourth rule constructs 
the whole permissible flow tree whose root is a write execution. The last rule 
resolves conflicts. 

5. Related Work 

Row control is a heavily researched aiea in the context of multi-level secu- 
rity. In the early days, Bell and LaPadula |2j and Denning [4] proposed the 
lattice based models of information flow. Some flexibility to EXinning's lattice 
based model was later added by Foley [6], where each entity was associated 
with a label pair instead of a single label, 

McCollum et al. (10] presented an Owner Retained Access Control model 
(ORAC) to control information dissemination. Based on the same idea, Myers 
and Liskov (11] provided a language-based information flow control model. 
Sajnarati et al. (12) presents an information flow control model for object- 
oriented system. Ferrari et al. [5] extend that model by allowing waivers asso- 
ciated with methods. 

Our work has been influenced by the Flexible Authorization Framework 
(FAF) of Jajodia et al. (9). FAF is proposed for specification of access con- 
trol policies, but not flow control policies. To our best knowledge, RexRow is 
the first flexible logic framework for flow control policies specification. 

6. Conclusions 

The FlexRow framework specifics flow control policies as stratified logic 
programs consisting of five levels. Both permissions and prohibitions arc 
specifiable in FlexRow, By expressing flow control pobeies at the program- 
ming language and transaction specification we have shown the generality of 
FlexRow. 
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Abstract: This paper first describes the developments in data and applications security 

with a special emphasis on database security. It also discusses current work 
including .security for data warehouses and e-commercc systems. Then it 
discuses some of the directions for data and applications security which 
in eludes .secure semantic web, .secure dependable information management, and 
secure sensor information management. Directions for privacy research are also 
given. 



Key words: Database Security, Secure Semantic Web. Secure Dependable Information 

Management, Secure Sensor Information Management, Privacy 



1. INTRODUCTION 

Rcccni developments in information systems technologies have resulted in 
computerizing many applications in various business areas. Data has become 
a critical resource in many organizations, and therefore, efficient access to 
data, sharing the data, extracting information from the data, and making use 
of the information has become an urgent need. As a result, there have been 
many efforts on not only integrating the various data sources scattered across 
several sites, but extracting information from these databases in the form of 
patterns and trends has also become important. These data sources may be 
databases managed by database management systems, or they could be data 
warehoused in a repository from multiple data sources. 

The advent of the World Wide Web (WWW) in the mid 1990s has 
resulted in even greater demand for managing data, information and 
knowledge effectively. There is now so much data on the web that managing 
it with conventional tools is becoming almost impossible. New tools and 
techniques arc needed to effectively manage this data. Therefore, to provide 
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interoperability as well as warehousing between the multiple data sources 
and systems, and to extract information from the databases and warehouses 
on the web. various tools arc being developed. 

As the demand for data and information management increases, there is 
also a critical need for maintaining the security of the databases, applications 
and information systems. Data and information have to be protected from 
unauthorized access as well as from malicious corruption. With the advent of 
the web it is even more important to protect the data and information as 
numerous individuals now have access to this data and information. 
Therefore, we need effective mechanisms for securing data ajid applications. 

This paper will review the developments in data and applications 
security with a special emphasis on database security. Then it will provide 
directions for data and applications security. These directions include 
securing emerging applicadons such as secure semantic web, secure 
sensor/stream information processing and privacy. 



2. DEVELOPMENTS IN DATABASE SECURITY 

Initial developments in database security began in the 1970s, For 
example, as part of the research on System R at IBM Almaden Research 
Center, there was a lot of work on access control for relational database 
systems. About the same dme, some early work on multilevel secure 
database management systems (MLS/DBMS) was reported. 

However it was only after the Air Force Summer Study in 1982, that 
much of the developments on secure database systems began (sec [1]). There 
were the early prototypes based on the integrity lock mechanisms developed 
at the MITRE Corporation. Later in the mid-1980s pioneering research was 
carried out at SRI International and Honeywell Inc. on systems such as 
ScaView and Lock Data Views. Some of the technologies developed by these 
research efforts were transfened to commercial products by corporations 
such as Oracle, Sybase, and Informix. 

The research in the mid 1980s also resulted in exploring some new areas 
such as the inference problem, secure object database systems, secure 
transaction processing and secure distributed/federated database systems. In 
fact Dr. John Campbell of the National Security Agency stated in 1990 is that 
one of the important developments in database security was the work of 
Thuraisingham on the unsolvability of the inference problem [6]. This 
research then led the way to examine various classes of the inference 
problem. Throughout the early 1990s, there were many efforts reported on 
these new types of secure database systems by researchers at organizations 
such as The MITRE Corporation. Naval Research Laboratory, University of 
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Milano and George Ma«;on University. In addition much work was also 
carried out on secure transactions processing. 

In the mid 1990s, with the advent of the web, there were many new 
directions for secure data management research. These included secure 
workflow systems, secure digital libraries, web security, and secure data 
warehouses. New technologies such as data mining exacerbated the inference 
problem as even naive users could now use data mining tools and infer 
sensitive information. However data mining is also a very important 
technique for solving many security problems such as intrusion detection and 
auditing. Therefore the challenge is to carry out data mining but at the same 
time ensuring that the inference problem is limited. Furthermore, with 
developments in distributed object systems and e-commerce applications, 
resulted in developments in secure distributed object systems and secure e- 
commerce applications. In addition, access control also has received a lot of 
attention especially in the area ofrolc-bascd access control (RBAC). A fairly 
comprehensive survey of data management security is reported in the article 
by Ferrari and Thuraisingham [11]. In this survey, the authors have given 
numerous references to research in database security starting around the 
1970s until around the late 1990s. Also, many of the publications in secure 
data management have appeared in the Proceedings of the IHIP 11.3 Working 
Conferences on Data and Applications Security [15] as well as in the 
proceedings of various security and database conferences. Numerous 
researchers all over the world have contributed toward the developments in 
database and applications security, A listing of all the references is beyond 
the scope of this paper. 



3. DIRECTIONS FOR DATA AND APPLICATIONS 

SECURITY 

3.1 Overview 

In sccdon 2 we provided a brief overview of the developments in secure 
data management over a thirty-year period starting around the early 1970s 
until the late 1990s, While there have been many developments in web 
security, there is still a lot of work to be done. Every day we arc seeing 
developments on web data management. For example, standards such as 
XML (extensible Markup Language), RDF (Resource Description 
Framework) arc emerging. Security for these web standards has to be 
examined. Also, web serviees arc becoming extremely popular and necessary 
for many applications and therefore we need to examine secure web services. 
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Semantic web is a concept that will soon become a reality. We need to 
examine security issues for the semantic web (see for example, [12]). 

Security needs to be examined for new application areas such as 
bioinformatics, peer-to-peer computing, grid computing, and stream/sensor 
data management. For example, in the case of bioinformatics, it is important 
that information about the genes of the individuals be protected from 
unauthorized users. Peer-to-peer computing has received a lot of attention 
recently. There arc numerous security issues for such systems including 
secure information sharing and collaboration. Furthermore, data is no longer 
only in structured databases. Data could be streams emanating from sensors 
and other sources as well as text, images and video. Security for such data 
has not received much attention. One also has to make tradeoffs between 
security, data quality and real-time processing. In other words, we need 
research on quality of service for information processing. Grid computing is 
developing rapidly especially to develop infrastructures and tools for 
scientists and engineers to carry out research. We need to ensure that the 
grids are secure. Finally we need to ensure that individual privacy is 
maintained especially when tools for data mining arc used to extract 
information for national security purposes. 

In summary, as new technologies emerge there arc lot of security issues 
that need to be examined. Furthermore, as technologies arc being developed 
for organizations and societies such as knowledge management and 
collaboration tools, we need to examine the security impact on these tools 
and technologies. While we have made a lot of progress in data and 
applications security the last three decades, there arc many more security 
issues that need to be examined in the next several decades. To address these 
issues, there arc now various research programs being funded in USA and in 
Europe. A description of the Cyber Trust Theme funded by the National 
Science Foundation, which includes data, and applications security can be 
found in [19]. A discussion of some previous efforts can be found in [26]). 

The remaining sections will focus on some of the specific directions in 
secure semantic web. secure dependable information management, and 
secure sensor information management and privacy. These were some of the 
direction discussed during the keynote presentation at the IFIP 11.3 Data and 
Applications Security Conference in Colorado on August 3. 2003 (sec [27], 
There are many more areas that need work in security including 
bioinformatics, geoinformatics, and scientific and engineering informatics in 
general, peer-to-peer information management, and information management 
for pervasive and mobile computing, A discussion of the security issues for 
all of these areas is beyond the scope of this paper. Note also that we have 
not discussed topics such as critical infrastructure protection and information 
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assurance for dalabaies in this paper. For a detailed discussion of database 
and applications security, we refer to [34]. 

3^ Secure Semantic Web 

While the current web technologies facilitate the integration of 
information from a syntactic point of view, there is still a lot to be done to 
integrate the semantics of various systems and applicadons. That is. current 
web technologies depend a lot on the human-in-the-loop for information 
integration. Tim Berners Lee, the father of WWW, realized the inadequacies 
of current web technologies and subsequently strived to make the web more 
intelligent. His goal was to have a web that will essentially alleviate humans 
from the burden of having to integrate disparate information sources as well 
as to carry out extensive searches. He then came to the conclusion that one 
needs machine understandable web pages and the use of ontologies for 
information integration. This resulted in the notion of the semantic web [17], 
Tim Berners Lee has specified various layers for the semantic web. At 
the lowest level one has the protocols for communication including TCP/IP 
(Transmission Control Protocol/Internet pn>tocol), HTTP (Hypertext 
Transfer Protocol) and SSL (Secure Socket Layer). The next level is the 
XML (extensible Markup Language) layer that also includes XML schemas. 
The next level is the RDF (Resource Description Framework) layer. Next 
comes the Ontologies and Interoperability layer. Finally at the highest-level 
one has the Trust Management layer. For the semantic web to operate 
successfully we need to ensure that security is maintained within and across 
all of the layers. In this section we provide an overview of the security issues 
for the semantic web. 

As stated earlier, logic, proof and trust are at the highest layers of the 
semantic web. That is. how can we trust the information that the web gives 
us? Closely related to trust is security. However security cannot be 
considered in isolation. That is. there is no one layer that should focus on 
security. Security cuts across all layers and this is a challenge. For example, 
consider the lowest layer. One needs secure TCP/IP, secure sockets, and 
secure HTTP, There are now security protocols for these various lower layer 
protocols. One needs end-to-end security. That is, one cannot just have 
secure TCP/IP built on untrusted communication layers, TTiat is, we need 
network security. Next layer is XML and XML schemas. One needs secure 
XML (sec [4], [5]). That is, act*ess must be controlled to various portions of 
the document for reading, browsing and modifications. There is research on 
securing XML and XML schemas. The next step is securing RDF, Now with 
RDF not only do we need secure XML, we also need security for the 
interpretations and semantics. For example under certain context, portions of 
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the document may be Unclassified while under certain other context the 
document may be Classified. As an example one could declassify an RDF 
document once the war is over. Lot of work has been carried out security 
constraint processing for relational databases. One needs to determine 
whether these results could be applied for the semantic web (see (23)), 

Once XML and RDF have been secured the next step is to examine 
security for ontologies and interoperation. That is, ontologies may have 
security levels attached to them. Certain parts of the ontologies could be 
Secret while certain other parts may be Unclassified, The challenge is how 
does one use these ontologies for secure information integration? 
Researchers have done some work on the secure interoperability of 
databases. We need to revisit this research and then determine what else 
needs to be done so that the information on the web can be managed, 
integrated and exchanged securely. 

Closely related to security is privacy. That is. certain portions of the 
document may be private while certain other portions may be public or semi- 
private, Privacy has received a lot of attention recently partly due to national 
security concerns. Privacy for the semantic web may be a critical issue, That 
is, how does one take advantage of the semantic web and still maintain 
privacy and sometimes anonymity. 

We also iteed to examine the inference problem for the semantic web. 
Inference is the process of posing queries and deducing new information. It 
becomes a problem when the deduced information is something the user is 
unauthorized to know. With the semantic web. and especially with data 
mining tools, one can make all kinds of inferences. That is the semantic web 
exacerbates the inference problem (see [24]). Recently there has been some 
research on controlling unauthorized inferences on the semantic web. We 
need to continue with such research (see for example. (10)), 

Security should not be an afterthought. We have often heard that one 
needs to insert security into the system right from the beginning. Similarly 
security cannot be an afterthought for the semantic web. However, we cannot 
also make the system inefficient if we must guarantee one hundred percent 
security at all times. What is needed is a flexible security policy. During 
some situations we may need one hundred percent security while during 
some other situations say thirty percent security (whatever that means) may 
be sufficient. 

33 Secure Dependable Information Management 

Dependable information systems are systems that are secure, survivable. 
fault tolerant and can process data in real-time. There is quality of service 
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tradeoffs that one needs to make to build dependable information systems. 
Various information systems including the semantic web have to be 
dependable. That is, these systems need to be secure, survivable and process 
data in real-time if needed. 

Our previous experience on building next generation command and 
control systems using real-time objects will form the basis for the discussion 
on dependable information management. Our infrastructure for the 
dependable system will consist of objects that have to perform many 
functions such as interprocess communication as well as memory 
management. These objects have to incorporate security, real-time processing 
and fault tolerant computing capabilities. The data managers have to process 
queries, execute transactions and manage data that may be transient. Data 
may also be mined to extract information. 

The data/information manager will manage various types of data 
including track data and data for multi -sensor information integration and 
fusion. The data/information manager will be hosted as an application on the 
object-based infrastructure. Processing may be distributed among multiple 
nodes ajid there has to be coordination between the nodes. Essentially we arc 
proposing a distributed information management system. One could also 
think of this system as a pccr-to-pccr system where the nodes arc peers that 
have to work together to solve a problem. 

For many applications timing constraints may be associated with data 
processing. That is. the data may have to be updated within a certain time or 
it may be invalid. There arc tradeoffs between security and real-time 
processing. That is. it takes time to process the access control rules and as a 
result, the system may miss the deadlines. Therefore, we need flexible 
security policies. In certain cases real-time processing may be critical. For 
example if we arc to detect anomalies from the time a person checks in at the 
ticket counter until he boards the airplane, then this anomaly has to be 
detected within a certain time. In this case we may have to sacrifice some 
degree of security. In other ca.ses. we may have a lot of time to say analyze 
the data and in this case only authorized individuals may access the data. 

One possibility for developing dependable infrastructures and data 
managers for sensor networks is to follow the approach we have developed 
for real-time command and control systems such as AWACS (Airborne 
Warning and Control System). Here we developed aji infrastructure 
consisting of a real-time object request broker and services using commercial 
real-time operating systems. We then developed a real-time data manager and 
applications hosted on the infrastructure. We used object technology for 
integrating the various components. We also showed how such aji 
infrastructure could be used to migrate legacy applications (see [3], [25]), 
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Wc can lake a similar approach to build an integrated system for 
dependable information systems. Wc need appropriate operating systems and 
infrastructures possibly based on object request brokers. We need to host 
dependable data managers and applications such as multi-sensor data 
integration and fusion on the infrastructures, Wc need to ensure that the 
system is secure and survivable. Wc also need to ensure that the 
infrastructure is secure. That is, security has to be built into the system and 
not considered as an after-thought. Essentially wc are proposing a layered 
architecture for dependable information management. The infrastructure 
consists of middleware possibly based on object request brokers for sensors. 
The objects that constitute the middleware include objects for interprocess 
communication, memory management, and support for data fusion and 
aggregation. On top of the infrastructure we host a dependable data manager. 
Wc also need to examine both centralized and distributed architectures for 
dependable data management. On the one hand wc can aggregate the data and 
send it to a centralized data management system or wc can develop a full- 
fledged distributed data management system. Wc need to conduct simulation 
studies and determine tradeoffs between various architectures and 
infrastructures. 

As part of our work on cvolvablc real-time command and control systems 
wc exajnincd real-time processing for object request brokers and we were 
instrumental in establishing a special interest group, which later bccajnc a 
task force within the Object Management Group (OMG), Subsequently 
commercial real-time object request brokers were developed. The question is, 
do we need special purpose object request brokers for dependable networks? 
Our challenge now is to develop object request brokers for dependable 
systems. Wc need to examine special features for object request brokers for 
managing data for dependable systems. 

Another aspect that is imporlanl is end-to-end dependability. This 
includes security, real-time processing and fault tolerance for not only all of 
the components such as infrastructures, data managers, networks, 
applications and operating systems; we also need to ensure the dependability 
of ihe composition of ihe entire system. This will be a major challenge even 
if we consider security, real-time processing and fault tolerant computing 
individually. Integrating all of them will be a complex task and will have to 
address many research issues and challenges. 



3.4 Secure Sensor Information Management 

Wc need to conduct research on security for sensor databases and sensor 
information systems. Note that sensor information management is one aspect 
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of dependable information management. For example, can we apply various 
access control techniques for sensor and stream databases? That is, can we 
give access to the data depending on the roles of the users such as the air port 
security officer has access to all of the sensor data emanating from the 
sensors while the airport ticketing agent may have limited access to certain 
sensor data. Another challenge is granting access to aggregated data. 
Individual data may be unclassified while the aggregated data may be highly 
sensitive. This is in a way a form of the inference problem in database 
systems. Note that inference is the process of posing queries and obtaining 
unauthorized information from the legitimate responses received. Due to the 
aggregation and fusion of sensor data, the security levels of the aggregated 
data may be higher than those of the individual data sets. We also need to be 
aware of the privacy of the individuals. Much of the sensor data may be 
about individuals such as video streams about activities and other personal 
information. This data has to be protected from the general public and from 
those who arc unauthorized to access the data. We have looked at privacy as 
a subset of security (see for example. [28|). There is also research on privacy 
preserving data mining and the techniques have to be examined for sensor 
data mining. 

Finally we need to examine security policies for sensor data. These 
security policies may be dynamic and therefore we need to develop ways to 
enforce security constraints that vary with time. We also need techniques for 
integrating security policies especially in a networked and distributed 
environment. For example, different policies may apply for different sensor 
databases. These policies have to be integrated when managing distributed 
databases. One of the major questions here is what are the special 
considerations for security for sensor and stream data? Do the access control 
models that have been developed for business data processing applications 
work for stream data? We need to start a research program on secure sensor 
networks and secure sensor information management. Some preliminary 
directions arc given in [28|. 

We need end-to-end security. That is, the infrastructures, data managers, 
applications, networks and operating systems for sensor information 
management have to be secure. The Object Management Group has 
developed standards for securing object request brokers. We need to take 
advantage of such developments. However, we need to examine security 
issues specific to object request brokers for sensor information management. 
We also need to examine composability of the various secure components. 
For example, arc the interfaces between the various components satisfying 
the security properties? How can we integrate or compose the security 
policies of the various components. There is little work reported on securing 
large-scale information systems. Now, we not only have to examine security 
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for such systems, we also need to examine security for such systems that 
manage and process sensor data. In addition, we need not only secure sensor 
networks but also sensor networks that arc dependable and survivable. 

One approach is to develop various features incrementally for data 
managers and middleware. However this often means that at the end some 
features are left out. For example, if we build components and examine only 
security and later on examine real-time processing, then it may be difficult to 
incorporate real-time processing into the policy. This means that we need to 
examine all of the features simultaneously. This means security engineering 
has to be integrated with software engineering. 

Other issues include fault tolerant sensors and survivable sensors. Much 
work has been canied out on fault tolerant data management. We need to 
examine the fault tolerant data processing techniques for sensor data. 
Furthermore, these sensor databases have to survive from failures as well as 
from malicious attacks. Many of our critical infrastructures such as our 
telephones, power lines, and other systems have embedded sensors. The data 
emanating from these sensors may be corrupted maliciously or otherwise. For 
example, how can we ensure that the aggregate data is valid even if the 
components that constitute the aggregate data may be corrupted? Some 
directions arc given in [20]. 

3.5 Privacy in Databases 

With the World Wide Web, there is now an abundance of information 
about individuals that one can obtain within seconds. This information could 
be obtained through mining or just from information retrieval. Data mining is 
the process of posing queries and extracting information previously unknown 
machine learning and other reasoning techniques (see [24]), Now, data 
mining is an important technology for many applications. However data 
mining also causes privacy concerns as users can now put pieces of 
information together and extract information that is sensitive or private. 
Therefore, one needs to enforce controls on databases and data mining tools. 
That is, while data mining is an important tool for many applications, we do 
not want the information extracted to be used in an incorrect manner. For 
example, based on information about a person, an insurance company could 
deny insurance or a loan agency could deny loans. In many cases these 
denials may not be legitimate. Therefore, information providers have to be 
very careful in what they release. Also, data mining researchers have to 
ensure that privacy aspects arc addressed. 

We are beginning to realize that many of the techniques that were 
developed for the past two decades or so on the inference problem can now 
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be used to handle privaey. One of the challenges lo securing databases is the 
inference problem (see [ 1 ]), Inference is the process of users posing queries 
and deducing unauthorized information from the legitimate responses that 
they receive. This problem has been discussed quite a lot over the past two 
decades (see [21], [18], [14]). However, data mining makes this problem 
worse. Users now have sophisticated tools that they can use to get data and 
deduce patterns that could be sensitive. Without these data mining tools, 
users would have to be fairly sophisticated in their reasoning to be able to 
deduce information from posing queries to the databases. That is. data 
mining tools make the inference problem quite dangerous [7]. While the 
inference problem mainly deals with secrecy and confidentiality we are 
beginning to sec many parallels between the inference problem and what we 
now call the privacy problem. 

When Inference problem is considered to be a privacy problem, then we 
can use the inference controller approach to address privacy. For example, 
we can develop privacy controllers similar to our approach to developing 
inference controllers [22], Furthermore, we can also have different degrees 
of privacy. For example, names and ages together could be less private while 
names and salaries together could be more private. Names and healthcare 
records together could be most private. One can then assign some probability 
or fuzzy value associated with the privacy of an attribute or a collection of 
attributes. Lot of work has been carried out on the inference problem in the 
past. We have conducted some research on applying the techniques for 
handling the inference problem and apply them for the privacy problem. We 
discuss some of the directions here. 

In one area of research we have designed a privacy enhanced database 
management system (PE-DBMS) where users with different roles access and 
share a database consisting of data at different privacy levels. A powerful and 
dynamic approach to assigning privacy levels to data is one, which utilizes 
privacy constraints. Privacy constraints provide a privacy policy. They can be 
used to assign privacy levels to the data depending on their content and the 
context in which the data is displayed. They can also be used to dynamically 
reclassify the data. In other words, the privacy constraints arc useful for 
describing privacy-enhanced applications. In [29] we have described the 
design if a PE-DBMS that processes privacy constraints during database 
design as well as during query and update operations. Recently Jajodia et al 
have proposed an approach for release control in databases (see [16], The 
idea here is to process constraints after the response is computed but before 
the document is released. This approach could also be adapted for privacy. 
Another direction for privacy in databases includes using semantic data 
models for describing the application, reasoning about the application and 
detecting privacy violations. Some preliminary results arc reported in [30]. 
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Wc have also proved thal the general privacy problem is unsolvabic and the 
next step is lo examine the complexity of the privacy problem (see [3J]). 
Essentially we have examined our previous work on the inference problem 
and adapted it to handle the privacy problem. 

There is now research at various laboratories on privacy 
enhanced/sensitive data mining (e,g., Agrawal at IBM Almadcn, Gchrkc at 
Cornell University and Clifton at Purdue University, see for example (2). [8], 
113], [9]). The idea here is to continue with mining but at the same time 
ensure privacy as much as possible. For example. Clifton has proposed the 
use of the multiparty security policy approach for carrying out privacy 
sensitive data mining. While there is some progress we still have a long way 
to go. A summary of the developments in privacy preserving data mining is 
given in [32]. For a detailed discussion of data mining for national security 
and the implications for privacy we refer to [33]. 

3.6 Other Security Considerations 

As we have mentioned in section 3.1, numerous technologies have 
emerged over the past few years. These include tools for electronic 
conunercc. gene extraction, geospatial information management, managing 
moving objects, grid computing, peer-to-peer information management, 
managing virtual societies and organizations, and pervasive and context 
aware computing. Security as well as privacy must be exajnined for these 
tools and technologies for them to be useful and effective. For example, wc 
could have the best grid computing tools, bul if these tools cannot maintain 
security and privacy at an acceptable level, then they may not be of much 
use. 

We also need to conduct research on usability vs, security. For example, 
security enforcement techniques may be quite complicated that it takes time 
to enforcement them. As a result, one could miss deadlines and/or lose 
valuable information. In other words, often there is a trade-off between 
security and technologies. How do wc evaluate the economic aspects for 
incorporating security. That is. would it be economically infeasible to 
enforce all of the access control policies? Do wc have to live with partial 
security? On the other hand by not having security, banks and financial 
organizations could lose millions of dollars through fraud. Here cyber 
security helps economic security. In other words, while security may be 
expensive to incorporate, for many applications wc could lose millions of 
dollars by not enforcing security, Wc need to carry out trade off studies and 
examine the return on investment for incorporating security. 
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4. SUMMARY 

This paper has briefly discussed the developments in data and 
applications security and then described some directions. We first provided a 
brief overview of the some of the developments in multilevel secure database 
management systems including relational systems, objects systems, 
transaction processing, and the inference problem. In the area of directions, 
we listed many topics such as secure grid computing, secure bioinformatics 
and secure geospatial information systems and then focussed on some 
selected topics such as secure semantic web, secure dependable computing, 
secure sensor information management and privacy in databases. We chose 
these topics as they arc relevant to our current research and also they 
elaborate on the some of the issues covered during the keynote presentation. 

As we have stressed in this paper, all of the topics listed here arc 
important. That is. we need to conduct research on secure pervasive 
computing as well as examine the economic a.spects of incorporating 
security. We also need to examine the security impact on knowledge 
management tools for societies and organizations. While we have made good 
progress, there is still a lot of research that needs to be done on data and 
applications security. Organizations such as the National Science Foundation 
now have focussed programs on Cyber security, which includes data and 
applications security. We can expect some significant developments on 
security for new gcncradon information management technologies over the 
next several years. 
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Abstract With more than 93% of the world's data being computer generated (23), digital 
forensics offers significant opponunilies and challenges. niLs paper discusses the 
operational and legal issues related U) digital evidence. In addition, it highlights 
current needs and future research opportunities. 

Keywords: Digital Evidence, Computer and Network Forensics. Forensic Prcoavscs, Legal 

Issues. Research Directions 

1. Introduction 

Digital forensics played a crucial role in Ihe invesligations of the 9-11 ter- 
rorisls, Ihe Enron, WorldCom and Martha Stewart scandals, and Ihe DC sniper 
attacks. In the sniper case, electronic data extracted from a GPS device in the 
suspects’ automobile provided information about their route across the country. 
Three unsolved murders along this route, in Louisiana, Alabama and Georgia, 
which involved weapons of the same caliber as the DC attacks, were connected 
to the sniper suspects via ballistics and fingerprint evidence. Indeed, due to 
network convergence and Ihe ubiquity of embedded systems and devices, prac- 
tically every crime - not just white-collar crime - has a digital forensic com- 
ponent [9,15,21). Laptops, cell phones and PDAs seized from drug dealers 
and other violent criminals often yield vital evidence [15,21]. Meanwhile, 
electronic evidence is playing an increasingly important role in civil lidgation. 
This paper discusses the opcradonal and legal issues related to digital evidence. 
In addition, it highlights current needs and future research opportunities. 

2. Operational Issues 

Computers and other electronic devices invariably contain information rel- 
evant to investigations. This is the electronic analog of Locard's forensic prin- 
ciple of "exchange," where "every contact leaves a trace" [10]. This section 
discusses the nature of digital evidence and Ihe forensic process, i.e., the ex- 
traction and analysis of digital evidence. 
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2.1. Digital Evidence 

A crime scene contains obscrvj^le evidence, e,g., blood, which has probative 
value. However, forensic science has developed techniques, e.g., DNA analysis, 
that yield information that is not physically observable. Computers, hard drives 
and flash memory cards arc patent (observable) evidence that contain latent 
information, e.g.. files, application metadata, file system debris and operating 
system debris. Extracting and analyzing latent evidence requires specialized 
tools and techniques. Moreover, the "forensic specialists” who perform these 
activities must be well trained and capable of providing expert testimony [18], 

The Scientific Working Group on Digital Evidence (SWGDE) has defined 
digital evidence as: "information of probadve value stored or transmitted in 
digital form" [6]. This definition is now widely accepted by other groups, e.g., 
the International Organization on Computer Evidence and the G-8 High Tech 
Crime Subcommittee. 

2.2. Digital Forensics 

Various terms, e.g.. computer forensics, cyber forensics, media analysis and 
network forensics, are used to refer to the process of acquiring, preserving, ex- 
amining. analyzing and presenting digital evidence. We prefer "digital evidence 
forensics.” or simply, "digital forensics." 

2.2.1 Acquisition. In the acquisition step, electronic devices at the scene 
are gathered, marked for identification and entered into an evidence control 
system. When evidence resides on devices that cannot - for legal or practical 
rea.sons - be physically collected, e.g.. a hospital network containing "live" 
medical data, it is necessary to create a physical duplicate of the evidence. Dy- 
namic evidence, e.g.. network packets in transit, must be captured and recorded 
on physical media, both accurately and reliably. 

2.22 Preservation. The preservation step requires the "original" piece 
of digital evidence to be maintained so that the opposing counsel and the court 
may be assured that it is both reliable and unaltered [12]. Failure to do so may 
result in the inadmissibility of evidence. Consequently, forensic examinations 
are almost always conducted on duplicate media [11]. 

Thus, preservation has two components: physical preservation of the original 
and the creation of duplicate media for forensic examination. The former is 
accomplished via "chain of custody" procedures; the latter by creating either a 
forensically accurate duplicate or a demonstrably accurate representation of the 
original. Tlie latter process is often referred to as creating a "forensic image” 
or a "bit-stream copy.” 
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2J3 Exammation. Modem computers and data storage devices have 
huge, ever increasing capacities, making it extremely difficult to identify in- 
formation of probative value. Examination is the process whereby evidence is 
subjected to review for its soiuce, origin, and manner of creation, alteration or 
destruction. 

The first step is to document all aspects of the evidence, e.g,. physical and 
logical characteristics, active and deleted file structures, metadata and data 
contained in unallocated areas. This documentation process assures that both 
inculpatory and exculpatory information is preserved. Next, the actual exam- 
ination may begin. Since examinations arc usually conducted to support legal 
proceedings, the nature and specifics of the evidence that would be probative is 
unique to each examination [20j. Therefore, it is important to define a plan of 
action and to select forensic software tools based on the goals of an examination. 

Numerous forensic tools, including many of dubious quality, arc available. 
Sometimes software not designed forforcnsic use is pressed into serviee, but this 
may raise legal challenges to the evidence or, even worse, render the evidence 
useless. Collectively, tools seek to include data as potentially probative or to 
exclude data that would not be probative. Obviously, the more restrictive the 
filter, the less data there will be to sift through, but it is also more likely that 
probative information will be missed The ability to construct a process that 
invokes the fewest and most appropriate tools in the most efficient way is the 
artistic part of forensic examination. As storage volume and network bandwidth 
grow exponentially, it will be increasingly difficult to create tools and processes 
that arc both efficient and accurate. 

234 A naly sis. Analysis i n vol ves the review of evidence for its content, 

probative value and usefulness to the investigative or legal objectives. Thus, 
analysis goes beyond the technical aspects of the original evidence and its 
constituent parts. While examination attempts to produce information that is 
potentially probative, it is not until the evidence is evaluated in the context 
of all of the other evidence that its value can be cstj^lishcd. Data recovered 
from the original evidence may support other information known in the ca.se, 
it may contradict other information in the ca.se, it may be new information, or 
it may prove to be non-pertinent. To make these determinations as accurately 
as possible, it is necessary to have a clear understanding of the investigative 
process and detailed knowledge of all the investigative material, 

233 Presentation. The output of forensic exatninadon and analysis 
comprises the data files extracted from the forensic copy of the original evi- 
dence and a report documendng the forensic process, pertinent metadata and 
conclusions. Obviously, the presen tadon must be complete, concise and clear. 
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3. Legal Constraints 

This section discusses U,S, laws governing the acquisition and use of digital 
evidence in criminal, civil and intelligence investigations. 

3.1. Criminal Investigations 

U,S. federal law relating to the acquisition of digital evidence by law en- 
forcement agencies is governed by the Fourth Amendment and statutory pri- 
vacy laws codified in the Wiretap Statute (18 U.S.C. Sections 2510-22). the 
Electronic Communications Privacy Act (ECPA) of 1986 (18 U.S.C. Sections 
2701-02) and the Pen/Trap Statute (18 U.S.C Sections 3121-27) [22,27). 

The Fourth Amendment limits the ability of government agents to obtain 
evidence without a warrant. A warrantless search does not violate the Fourth 
Amendment if: (i) the agents' conduct docs not violate an individual's “rea- 
sonable expectation of privacy,” or (ii) the search falls within an exception to 
the warrant requirement [5, 27.28). Therefore, agents must eonsidcr if a scareh 
violates the expectation of privacy. Even if a search docs violate this expec- 
tation, it may still be reasonable if it falls within an exception to the warrant 
requirement [27], 

Determining what constitutes a reasonable expectation of privacy is difficult 
in ca.scs involving computers. To assist federal investigators, the U,S. Justice 
Department recommends that agents treat a computer as a closed container 
(e,g., a flic cabinet) [27]. The Fourth Amendment prohibits law enforcement 
agents from accessing and viewing computer information without a warrant if 
they would be prohibited from opening a closed container and examining its 
contents in the same situation [27 1. However, courts have reached differing 
conclusions on whether or not individual computer files should be treated as 
separate closed containers. 

Wanantless searches that violate a rca.sonabIc expectation of privacy comply 
with the Fourth Amendment if they fall within an established exception to the 
warrant requirement. For example, agents may conduct a search without a 
warrant if an individual with authority has consented to the search, if there 
is an expectation that the evidence will be destroyed, or if the evidence is in 
plain view [16.27], Other exceptions occur during searches incident to a I awful 
arrest, inventory searches and border searches (27). 

Because courts may or may not apply an excepdon, it is advisable to obtain a 
wanant before searching and seizing evidence. As with any search pursuant to 
a warrant. law enforcement agents must establish probable cause, and describe 
the place to be searched and the items to be seized [27]. However, because com- 
puter files may be encrypted, misleadingly labeled, stored in unusual formats 
or commingled with innocuous files, agents cannot simply establish probable 
cause, describe the files they need, and then go and retrieve the data. Instead, 




Digital Forensics: Operational, Legal and Research Issues 



397 



they must understand the technical limits of different search techniques, plan 
the search carefully and then draft the wananl in a manner that authorizes them 
to lake Ihe steps necessary to obtain the evidence. 

Agents should obtain multiple warrants if they have reason to believe that 
a network search will retrieve data stored in multiple locations. Also, agents 
should obtain a second warrant to search a computer seized pursuant to a valid 
warrant if the property targeted by the search is different from that specified in 
the first warrant, 

Tlie incidenud seizure of certain materials may implicate the Privacy Protec- 
tion Act (PPA) or the ECPA [27]. Under the PPA. law enforcement agents must 
take special steps when planning a search that may result in the seizure of First 
Amendment materials (e.g„ materials posted on the web). The ECPA regulates 
how agents can obtain the contents of electronic communications stored by 
third-party service providers. To minimize liability under these statutes, agents 
should attempt to determine in advance the type of information that may be 
stored on the computer systems to be searched [27]. 

Law enforcement agents can conduct "no-knock" warrants if they suspect 
that announcing their presence would lead to the destruction of evidence [27], 
Courts may also authorize "sneak-and-peek" warrants, which do not require 
agents to notify the person whose premises are searched. The USA PATRIOT 
Act amended 18 U,S,C. Section 3103a to allow a court to grant a delay of notice 
associated with the execution of a search warrant if it believes that providing 
immediate nodflcation will have adverse effects [26]. However, warrants issued 
under the amended statute still prohibit the seizure of electronic information 
unless specifically authorized by a court. 

In addition to physically seizing computers, agents frequently perform elec- 
tronic surveillance. In these situations, it is important for agents to act in accord 
with the Wiretap Statute and the Pen/Trap Statute. The Wiretap Statute (Tide 
111) governs real-dme electn)nic surveillance in federal criminal investigations 
[7,24]. Title 10 broadly prohibits the intercepdon of oral, wire and electronic 
communications. However. Tide 10 contains dozens of exceptions and agents 
must be familiar with them before performing surveillance. The Pen/Trap 
Statute governs the use of pen registers and trap and trace devices [27]. Tlie 
statute authorizes a government attorney to apply for a court order authorizing 
the installation of a pen register and/or trap and trace device when the informa- 
tion sought is relevant to an investigation. As modified by the USA PATRIOT 
Act. it now applies to communications on computer networks in addition to 
telephone communicadons and gives nationwide effect to pen/trap orders [26]. 

In addition to the applicable federal laws, state laws must also be considered. 
In particular, many states have laws regarding privacy, especially with regard 
to stored electronic information. Unfortunately, laws vary considerably from 
state to state, and a detailed discussion is beyond the scope of this paper. It is 
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important to note that when there is conflict, federal laws supercede state laws. 
However, in some instances, state laws are more specific and arc, therefore, 
applicable. 

3^. Civil Investigations 

Private corporations investigating their own employees may not adhere to 
most of the legal constraints discussed above. Frequently, private corporations 
require employees to sign computer use policies that include stipulations regard- 
ing the monitoring of computer aedvities. In these cases, employees typically 
resign their privacy rights. 

The Fourth Amendment also does not apply to searches conducted by private 
parties who are not acting as agents of the government [27]. Therefore, no 
violation of the Fouith Amendment occurs when a private individual acting 
on his own accord conducts a search and makes the results available to law 
enforcement. However, law enforcement agents must limit themselves to the 
scope of the private search. Otherwise, the agents may violate the Fourth 
Amendment and any evidence gathered may be suppressed. 

33. Intelligence Investigations 

Searching, seizing or otherwise obtaining digital evidence in intelligence 
invesdgadons can raise difficult questions of both law and policy. For example, 
the bounds of the Fourth Amendment are less clear than they arc for ordinary 
criminal investigations [27]. Fuithermore, the Foreign Intelligence Surveillance 
Act (FISA) creates a secret court and a legal regime for counterintelligence 
surveillance inside the United States [25]. When operating outside the United 
States, agents must be aware of the many laws in other nations that may affect an 
investigation. The U.S. Department of Justice Computer Crime and Intellectual 
Property Section (CCIPS) provides guidance on these matters. 

4. Current Needs and Research Issues 

This section discusses some of the significant areas of opportunity for re- 
search in digital forensics, 

4.1. Data Storage and Analysis 

The amount of data generated and stored in our daily activities is increasing 
rapidly, A recent University of California at Berkeley study estimated that 
almost 800 megabytes of data are produced annually for each person in the 
world; moreover, the per person figure is growing at about 30% per year [2,17]. 
In this environment, forensic investigators are faced with massive amounts of 
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evidence on digital media and networks. Single eases involving more than one 
hundred terabytes of data have already been cneountcred. 

Storage area networks (SANs) arc an attractive solution [3). These high- 
speed spceial-purposc networks interconnect various data storage devices with 
massive data servers. SANs permit data from multiple ca.scs to be loaded 
on networks and accessed, possibly remotely, by investigators. They allow 
for both physical and logical separation of forensic case files; this prevents 
evidenee from being compromised, as with blood evidence in the well-known 
O.J. Simpson case. The increased storage capacity and scalability of SANs 
supports efficient information access, maximized hardware utilization, freedom 
from vendor dependence and the automation of forensic processes, SANs may 
also help solve current problems with long-term data storage by providing data 
redundancy (via RAID) and integrity. Promising research avenues include 
SAN architectures for large-scale, distributed operations, workflow modeling 
and analysis, validation and verification of SAN implementations, and the study 
of the legal ramifications of SAN use. 

Another strategy for dealing with massive case files is to apply novel infor- 
mation manipulation techniques that can home in on pertinent data both rapidly 
and reliably. The main information manipulation techniques arc data reduction 
and data mining. Data reduction methods involving known flic filters and hash 
sets are cuncntly used by forensic investigators, but these arc limited in both 
scope and performance. Data mining employs a combination of machine learn- 
ing, statistical analysis and modeling techniques to extract relevant information 
from large data sets. Data mining techniques arc just beginning to find appli- 
cadons in digital forensic investigations, and numerous research opportunities 
exist in this area, 

42 , Specialized Devices 

Digital investigations have largely concentrated on computers and networks. 
However, the ubiquity of hand-held electronic devices and new network appli- 
ances requires research on extracting digital evidence from non-traditional. and 
possibly damaged, equipment. Examples include fax machines, cell phones, 
smart cards. GPS navigational aids, digital cameras and various consumer elec- 
tronics devices. 

Fax machines store phone numbers of senders and recipients; upscale ma- 
chines often maintain the actual faxed pages in memory. Cell phones store 
substantial amounts of data: dialed, received and missed calls as well as con- 
tact lists, photographs and MMS files. Information stored in smart cards (and 
not-so-smart cards) may include toll road access data, ostensibly anonymous 
prepaid phone cards and supermarket purchases. GPS devices store detailed 
path information that has been extracted and used successfully in criminal and 
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terrorism investigations. Digital cajneras store data in memory chips, which 
arejust as ajnenablc to forensic techniques as traditional computer media, i.e.. 
deleted files are not really deleted and slack space (between end-of-file and 
end-of“Sector) will contain data. Like digital cajneras, a jnultitude of other con- 
sumer electronics devices, such as MP3 players and camcorders, have digital 
memories and may contain useful information. 

Embedded devices are an emerging trend. For example, automobiles now 
incorporate devices that store operational data, e,g„ speed, brake status and 
throttle position, that may be relevant to investigations. The recent fatality 
accident investigation involving U,S. Rep. William Janklow (R-SD) exemplifies 
the use of digital evidence extracted from embedded devices in an automobile 

HI. 

Research efforts should seek to identify electronic devices that may contain 
digital evidence and develop tools and techniques for extracting the evidence. In 
addition, it is necessary to develop best practices that jnect the legal requirements 
for evidence admissibility, 

43. Network Forensics 

Forensic investigations involving networks languish for practical, jurisdic- 
tional and political reasons. Network administrators have no incentive to retain 
data that may be relevant to investigations outside their networks. This prob- 
lem is even greater in situations where network nodes are located in foreign 
countries, especially non-friendly nations or those with different legal systems, 

A potential solution is to develop and implement techniques that would make 
anonymity and pscudoanonymity harder to achieve on global networks like the 
Internet; this would limit the need for cooperation of foreign parties. IPsec 
[13). for cxajnple, would have resulted in increased sender authentication, but 
the pressure for its implementation has dissipated due to the popularity of NAT, 
which removes the urgency for new IP addresses [4]. and SSL. which removes 
the urgency for a broadly accepted means to encrypt select traffic [8], 

Clearly, it is difficult to solve the cultural, economic, political andjurisdic- 
tional problems that stifle network forensic investigations. However, it may be 
easier to develop technologies that ride on current IPv4 - and future IPv6 - 
networks, which could assist in tracing attacks across global networks. These 
technologies could then be proposed to cognizant organizations, e.g,. IETF and 
IEEE, for possible codification as standards. 

Pecr-to-peer networks [19] and grid computing [14] arc two emerging re- 
search areas in network forensics. Peer-to-peer applications create transient 
Internet-based networks, which are increasingly used to trade copyrighted and 
other illegal materials. Grid computing networks, on the other hand, utilize 
transient pools of computing nodes to perfonn tasks, each node contributing 
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cycles to the collaborative effort. Special techniques and tools must be devel- 
oped to deal with the scale, jurisdictional and dynamic participation issues in 
these two types of networks. 

4.4. Forensic Tools and Processes 

Forensic tools have advanced considerably during the past few years. Nev- 
ertheless. the development of highly efficient software that can be utilized on 
a variety of platforms on a wide range of target systems in a modular fashion 
could narrow the gap between demand and functionality. 

It is equally important to study the forensic process to determine how to con- 
duct examinations most efficiently. Experienced examiners are very efficient, 
but no efforts have been undertaken to analyze and model their appniaches with 
a view to automadng the forensic examination process. 

Regardless of the tools and techniques used, it is imperative to ensure the 
efficiency and effectiveness of forensic examinations. Furthermore, as data, 
media, forensic tools and investigations become more complex, it is increasingly 
difficult to demonstrate the “truth" of a forensic examination. To address this 
issue, research is needed in several directions, including software engineering 
approaches for trusted forensic software, automated processes and tools, and 
the validation of software as it applies to a particular platform, data set and 
forensic procedure. 

4.5. Legal Considerations 

To ensure that digital evidence will withstand judicial scrutiny, it is neces- 
sary to research the reliability and legality of forensic tooh. techniques and 
pixKedures. 

As court proceedings increasingly incorporate digital evidence, judges, juries 
and attorneys are more likely to test the merit of digital forensic tools and 
methodologies. In the United States, judicial evaluations of digital evidence - 
as with other forensic disciplines - will apply the Frye. Daubert and Kumho 
Tire tests [18], Under these doctrines, the reliability of the proffered evidence 
must be demonstrated. This demands comprehensive validadon and verification 
studies of digital forensic tools, techniques and pnx:edures. Unfortunately, with 
the massive, dynamic electronic landscape, the digital forensics community has 
had limited success in developing dmely and efficient means for validation, let 
alone verification. 

Research on the privacy implications of digital forensic tools and procedures 
is critical. Even if tools and pixxedures are reliable and verifiable, investigators 
cannot wantonly seize digital devices and extract evidence. Electronic devices 
may store information protected by various privacy laws. Violating privacy laws 
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at any stage during the digital forensic process not only renders the collected 
evidence useless, but also exposes the investigator to civil action. 

5. Conclusions 

Sophisdeated tools and procedures are sorely needed to acquire, preserve, ex- 
amine, analyze and present digital evidence in adynamic electronic landscape. 
But it is equally important that the tools and procedures be used properly and 
legally. Digital forensics is indeed a wide open area for research. Its tech- 
nical, operational and legal dimensions pose myriad challenges and research 
opportunities. 
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